OLD | NEW |
(Empty) | |
| 1 # Referrer-Policy Web Platform Tests |
| 2 |
| 3 The Referrer-Policy tests are designed for testing browser implementations and c
onformance to the [W3 Referrer-Policy Specification](http://w3c.github.io/webapp
sec/specs/referrer-policy/). |
| 4 |
| 5 ## Project structure |
| 6 |
| 7 The project contains tools, templates and a seed (```spec.src.json```) for gener
ating tests. The main assertion logic resides in JS files in the root of the ```
./generic/``` directory. |
| 8 |
| 9 This is the overview of the project structure: |
| 10 |
| 11 ``` |
| 12 . |
| 13 └── generic |
| 14 ├── subresource - documents being served as sub-resources (python scripts) |
| 15 ├── subresource-test - sanity checking tests for resource invocation |
| 16 ├── template - the test files template used for generating the tests |
| 17 └── tools - for generating and maintaining the test suite |
| 18 └── (genereated_tests_for_a_specification_1) |
| 19 └── (genereated_tests_for_a_specification_2) |
| 20 └── ... |
| 21 └── (genereated_tests_for_a_specification_N) |
| 22 ``` |
| 23 |
| 24 ## The spec JSON |
| 25 |
| 26 The ```spec.src.json``` defines all the test scenarios for the referrer policy. |
| 27 |
| 28 Invoking ```./generic/tools/generate.py``` will parse the spec JSON and determin
e which tests to generate (or skip) while using templates. |
| 29 |
| 30 |
| 31 The spec can be validated by running ```./generic/tools/spec_validator.py```. Th
is is specially important when you're making changes to ```spec.src.json```. Ma
ke sure it's a valid JSON (no comments or trailing commas). The validator should
be informative and very specific on any issues. |
| 32 |
| 33 For details about the spec JSON, see **Overview of the spec JSON** below. |
| 34 |
| 35 |
| 36 ## Generating and running the tests |
| 37 |
| 38 The repository already contains generated tests, so if you're making changes, |
| 39 see the **Removing all generated tests** section below, on how to remove them be
fore you start generating tests which include your changes. |
| 40 |
| 41 Start from the command line: |
| 42 |
| 43 ```bash |
| 44 |
| 45 # Chdir into the tests directory. |
| 46 cd ~/web-platform-tests/referrer-policy |
| 47 |
| 48 # Generate the test resources. |
| 49 ./generic/tools/generate.py |
| 50 |
| 51 # Add all generated tests to the repo. |
| 52 git add * && git commit -m "Add generated tests" |
| 53 |
| 54 # Regenerate the manifest. |
| 55 ../manifest |
| 56 |
| 57 ``` |
| 58 |
| 59 Navigate to [http://web-platform.test:8000/tools/runner/index.html](http://web-p
latform.test:8000/tools/runner/index.html). |
| 60 |
| 61 Run tests under path: ```/referrer-policy```. |
| 62 |
| 63 Click start. |
| 64 |
| 65 |
| 66 ## Options for generating tests |
| 67 |
| 68 The generator script ```./generic/tools/generate.py``` has two targets: ```relea
se``` and ```debug```. |
| 69 |
| 70 * Using **release** for the target will produce tests using a template for optim
izing size and performance. The release template is intended for the official we
b-platform-tests and possibly other test suites. No sanity checking is done in r
elease mode. Use this option whenever you're checking into web-platform-tests. |
| 71 |
| 72 * When generating for ```debug```, the produced tests will contain more verbosit
y and sanity checks. Use this target to identify problems with the test suite wh
en making changes locally. Make sure you don't check in tests generated with the
debug target. |
| 73 |
| 74 Note that **release** is the default target when invoking ```generate.py```. |
| 75 |
| 76 |
| 77 ## Removing all generated tests |
| 78 |
| 79 ```bash |
| 80 # Chdir into the tests directory. |
| 81 cd ~/web-platform-tests/referrer-policy |
| 82 |
| 83 # Remove all generated tests. |
| 84 ./generic/tools/clean.py |
| 85 |
| 86 # Remove all generated tests to the repo. |
| 87 git add * && git commit -m "Remove generated tests" |
| 88 |
| 89 # Regenerate the manifest. |
| 90 ../manifest |
| 91 ``` |
| 92 |
| 93 **Important:** |
| 94 The ```./generic/tools/clean.py``` utility will only work if there is a valid ``
`spec.src.json``` and previously generated directories match the specification r
equirement names. So make sure you run ```clean.py``` before you alter the speci
fication section of the spec JSON. |
| 95 |
| 96 |
| 97 ## Updating the tests |
| 98 |
| 99 The main test logic lives in ```./generic/referrer-policy-test-case.js``` with h
elper functions defined in ```./generic/common.js``` so you should probably star
t there. |
| 100 |
| 101 For updating the test suite you will most likely do **a subset** of the followin
g: |
| 102 |
| 103 * Add a new sub-resource python script to ```./generic/subresource/```, |
| 104 and update the reference to it in ```spec.src.json```. |
| 105 |
| 106 * Add a sanity check test for a sub-resource to ```./generic/subresource-test/``
`. |
| 107 |
| 108 * Implement new or update existing assertions in ```./generic/referrer-policy-te
st-case.js```. |
| 109 |
| 110 * Exclude or add some tests by updating ```spec.src.json``` test expansions. |
| 111 |
| 112 * Update the template files living in ```./generic/template/```. |
| 113 |
| 114 * Implement a new delivery method via HTTP headers or as part of the test templa
te in ```./generic/tools/generate.py``` |
| 115 |
| 116 * Update the spec schema by editing ```spec.src.json``` while updating the |
| 117 ```./generic/tools/spec_validator.py``` and ```./generic/tools/generate.py``` |
| 118 and making sure both still work after the change (by running them). |
| 119 |
| 120 * Regenerate the tests and MANIFEST.json |
| 121 |
| 122 |
| 123 ## Updating the spec and regenerating |
| 124 |
| 125 When updating the ```spec.src.json```, e.g. by adding a test expansion pattern t
o the ```excluded_tests``` section or when removing an expansion in the ```speci
fication``` section, make sure to remove all previously generated files which wo
uld still get picked up by ```MANIFEST.json``` in the web-platform-tests root. A
s long as you don't change the specification requirements' names or remove them,
you can easily regenerate the tests via command line: |
| 126 |
| 127 ```bash |
| 128 |
| 129 # Chdir into the tests directory. |
| 130 cd ~/web-platform-tests/referrer-policy |
| 131 |
| 132 # Regenerate the test resources. |
| 133 ./generic/tools/regenerate |
| 134 |
| 135 # Add all the tests to the repo. |
| 136 git add * && git commit -m "Update generated tests" |
| 137 |
| 138 # Regenerate the manifest. |
| 139 ../manifest |
| 140 |
| 141 |
| 142 ``` |
| 143 |
| 144 |
| 145 ## Overview of the spec JSON |
| 146 |
| 147 **Main sections:** |
| 148 |
| 149 * **specification** |
| 150 |
| 151 Top level requirements with description fields and a ```test_expansion``` rule
. |
| 152 This is closely mimicking the [Referrer Policy specification](http://w3c.githu
b.io/webappsec/specs/referrer-policy/) structure. |
| 153 |
| 154 * **excluded_tests** |
| 155 |
| 156 List of ```test_expansion``` patterns expanding into selections which get skip
ped when generating the tests (aka. blacklisting/suppressing) |
| 157 |
| 158 * **referrer_policy_schema** |
| 159 |
| 160 The schema to validate fields which define the ```referrer_policy``` elsewhere
in the JSON. |
| 161 A value for a referrer_policy can only be one specified in the referrer_policy
_schema. |
| 162 |
| 163 * **test_expansion_schema** |
| 164 |
| 165 The schema used to check if a ```test_expansion``` is valid. |
| 166 Each test expansion can only contain fields defined by this schema. |
| 167 |
| 168 * **subresource_path** |
| 169 |
| 170 A 1:1 mapping of a **subresource type** to the URL path of the sub-resource. |
| 171 When adding a new sub-resource, a path to an existing file for it also must be
specified. |
| 172 |
| 173 |
| 174 ### Test Expansion Patterns |
| 175 |
| 176 Each field in a test expansion can be in one of the following formats: |
| 177 |
| 178 * Single match: ```"value"``` |
| 179 |
| 180 * Match any of: ```["value1", "value2", ...]``` |
| 181 |
| 182 * Match all: ```"*"``` |
| 183 |
| 184 #### Example: test expansion in a requirement specification |
| 185 |
| 186 The following example shows how to restrict the expansion of ```referrer_url```
to ```origin``` and allow rest of the arrangement to expand (permute) to all po
ssible values. The name field will be the prefix of a generated HTML file name f
or the test. |
| 187 |
| 188 ```json |
| 189 { |
| 190 "name": "origin-only", |
| 191 "title": "Referrer Policy is set to 'origin-only'", |
| 192 "description": "Check that all sub-resources in all cases get only the ori
gin portion of the referrer URL.", |
| 193 "specification_url": "https://w3c.github.io/webappsec/specs/referrer-polic
y/#referrer-policy-state-origin", |
| 194 "referrer_policy": "origin", |
| 195 "test_expansion": [ |
| 196 { |
| 197 "name": "generic", |
| 198 "expansion": "default", |
| 199 "source_protocol": "*", |
| 200 "target_protocol": "*", |
| 201 "delivery_method": "*", |
| 202 "redirection": "*", |
| 203 "origin": "*", |
| 204 "subresource": "*", |
| 205 "referrer_url": "origin" |
| 206 } |
| 207 ] |
| 208 } |
| 209 ``` |
| 210 |
| 211 **NOTE:** An expansion is always constructive (inclusive), there isn't a negatio
n operator for explicit exclusion. Be aware that using an empty list ```[]``` ma
tches (expands into) exactly nothing. Tests which are to be excluded should be d
efined in the ```excluded_tests``` section instead. |
| 212 |
| 213 A single test expansion pattern, be it a requirement or a suppressed pattern, ge
ts expanded into a list of **selections** as follows: |
| 214 |
| 215 * Expand each field's pattern (single, any of, or all) to list of allowed values
(defined by the ```test_expansion_schema```) |
| 216 |
| 217 * Permute - Recursively enumerate all **selections** accross all fields |
| 218 |
| 219 Be aware that if there is more than one pattern expanding into a same selection
(which also shares the same ```name``` field), the pattern appearing later in th
e spec JSON will overwrite a previously generated selection. To make sure this i
s not undetected when generating, set the value of the ```expansion``` field to
```default``` for an expansion appearing earlier and ```override``` for the one
appearing later. |
| 220 |
| 221 A **selection** is a single **test instance** (scenario) with explicit values, f
or example: |
| 222 |
| 223 ```javascript |
| 224 var scenario = { |
| 225 "referrer_policy": "origin-when-cross-origin", |
| 226 "delivery_method": "meta-referrer", |
| 227 "redirection": "no-redirect", |
| 228 "origin": "cross-origin", |
| 229 "source_protocol": "http", |
| 230 "target_protocol": "http", |
| 231 "subresource": "iframe-tag", |
| 232 "subresource_path": "/referrer-policy/generic/subresource/document.py", |
| 233 "referrer_url": "origin" |
| 234 }; |
| 235 ``` |
| 236 |
| 237 Essentially, this is what gets generated and defines a single test. The scenario
is then evaluated by the ```ReferrerPolicyTestCase``` in JS. For the rest of th
e arranging part, see the ```./generic/template/``` directory and examine ```./g
eneric/tools/generate.py``` to see how the values for the templates are produced
. |
| 238 |
| 239 |
| 240 Taking the spec JSON, the generator follows this algorithm: |
| 241 |
| 242 * Expand all ```excluded_tests``` to create a blacklist of selections |
| 243 |
| 244 * For each specification requirement: Expand the ```test_expansion``` pattern in
to selections and check each against the blacklist, if not marked as suppresed,
generate the test resources for the selection |
| 245 |
OLD | NEW |