Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(326)

Side by Side Diff: third_party/WebKit/LayoutTests/external/wpt/referrer-policy/README.md

Issue 2697453005: Import wpt@758b3b4cfa805067f36121333ba031e583d3a62c (Closed)
Patch Set: Add -expected.txt files. Created 3 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(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
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698