Tue, 06 Jan 2015 21:39:09 +0100
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
michael@0 | 1 | This is a regression tester for http. |
michael@0 | 2 | |
michael@0 | 3 | The summary |
michael@0 | 4 | =========== |
michael@0 | 5 | |
michael@0 | 6 | 1) start the server, with python server.py |
michael@0 | 7 | 2) Get a file of all tests available by getting http://localhost:8000/ |
michael@0 | 8 | 3) Use that file as an argument to mozilla -f (this requires either a |
michael@0 | 9 | debug build or a build with --enable-perf-metrics) |
michael@0 | 10 | 4) Look at the results of http://localhost:8000/id/report |
michael@0 | 11 | |
michael@0 | 12 | Detail |
michael@0 | 13 | ====== |
michael@0 | 14 | |
michael@0 | 15 | Each run gets a unique ID number, which is used to map a test run to a |
michael@0 | 16 | database of results. Every test (which lives in the tests/ directory) is |
michael@0 | 17 | enumerated in step 2. Adding a new test is as simple as just creating the |
michael@0 | 18 | directory and addiing the appropriate files. |
michael@0 | 19 | |
michael@0 | 20 | Test format |
michael@0 | 21 | =========== |
michael@0 | 22 | |
michael@0 | 23 | Each test must have a config file, which is simply a list of all the files |
michael@0 | 24 | which will be requested, in order. Each file (x) can either be present in |
michael@0 | 25 | the directory as that name, in which case the contents will be sent to the |
michael@0 | 26 | browser, or as x.headers and (optionally) x.body. |
michael@0 | 27 | |
michael@0 | 28 | The headers file has a first line which is the response code, and then any |
michael@0 | 29 | subsequent lines are header: value pairs. If the body file is not present, |
michael@0 | 30 | the test server will construct a one line response. This is useful for |
michael@0 | 31 | testing mozilla's response to headers (see the responses/ subdirectory of |
michael@0 | 32 | tests for examples) |
michael@0 | 33 | |
michael@0 | 34 | Advanced tests |
michael@0 | 35 | ============== |
michael@0 | 36 | |
michael@0 | 37 | The default definition of a tests's 'success' is that all the files are |
michael@0 | 38 | retreived in the correct order. This can be overridden on a per test |
michael@0 | 39 | basis. For example, the referer test additionally checks that a |
michael@0 | 40 | referer header was sent. |
michael@0 | 41 | |
michael@0 | 42 | To do this, a file called tester.py must exist in the test's directory. |
michael@0 | 43 | This class must provide an object called tester, which is used by the |
michael@0 | 44 | driver code instead of the default tester. This default tester is |
michael@0 | 45 | automatically present in the file's namespace under the name 'BaseTester'. |
michael@0 | 46 | This means that it can be inherited from in order to only override certain |
michael@0 | 47 | functionality. |
michael@0 | 48 | |
michael@0 | 49 | The routines in the default tester are documented in BaseTest.py. The most |
michael@0 | 50 | common routine which needs to be extended in verify_request. For an |
michael@0 | 51 | example, see the referer test. |
michael@0 | 52 | |
michael@0 | 53 | Bradley Baetz <bbaetz@netscape.com>, <bbaetz@cs.mcgill.ca> |