| 9 | | There are no automated tests that exercise the user interface of the Web Inspector (UI tests). In practice, the Inspector UI changes frequently so such tests are very brittle, and are rarely worth the trouble of maintaining. Some manual tests focusing on UI exist in `ManualTests/inspector/`, but these are not maintained at the time of this writing. |
| | 9 | * **Protocol Tests** exercise the **inspector backend** independently of any particular frontend. |
| | 10 | * **Frontend Tests** exercise the **models and controllers** underlying the Web Inspector user interface. |
| | 11 | * **Manual Tests** exercise the user interface in ways that are difficult to automate or require infrastructure that doesn't exist yet. |
| | 12 | * **Library Tests** exercise subsystems such as pretty printing or the protocol generator in isolation from a running Web Inspector instance. |
| | 13 | |
| | 14 | To date, the Web Inspector has no automated tests that exercise the user interface. In practice, the Inspector UI changes frequently, so such tests tend to be brittle, and have traditionally not been worth the trouble of maintaining. |
| | 15 | |
| | 16 | == How Tests Execute |
| | 17 | |
| | 18 | Each test is an HTML file in a per-domain directory within `LayoutTests/inspector/`. Some tests may additionally include external files, which are included in special `resources/` directories that are automatically excluded from the test search path. All tests must decide which test harness to use by including either `protocol-test.js` or `inspector-test.js`. |
| | 19 | |
| | 20 | When the test page finishes loading, it calls the `runTest()` method provided, which signals the test harness to set up a test inspector instance that inspects the test page. Each test page defines a special `test()` method, which is automatically marshalled and injected into the Inspector instance's context. Most scripts execute in the inspector's JavaScript context, and occasionally evaluate some code in the test page's context to trigger specific inspectable behaviors. |
| | 21 | |
| | 22 | == How to Write Tests |
| | 23 | |
| | 24 | TODO |
| 15 | | Each test is an HTML file in the `LayoutTests/inspector-protocol/` directory. The special `test()` method is evaluated in the inspector page (see below), and other scripts are executed in the test page (i.e., the page being inspected by the inspector). |
| 16 | | |
| 17 | | === Dummy inspector frontend |
| 18 | | |
| 19 | | Many protocol and model tests do not need to persist across main frame navigations, nor do they need access all of the Web Inspector functionality. For such tests, the test harness creates a dummy inspector frontend by using `window.open()` from the test page, and establishes bidirectional communication with the __child__ inspector page using `window.postMessage` and a `message` event handler. It then evaluates a subset of inspector resources into existence on the dummy page. Finally, it runs the provided test function by calling `toString()` on the function, sending to the child inspector page, and then using `eval()`. This functionality is implemented by `LayoutTests/http/tests/inspector-protocol/resources/protocol-test.js` on the test page, and `LayoutTests/http/tests/inspector-protocol/resources/InspectorTest.js` on the inspector page. |
| | 30 | The protocol-test.js stub creates a dummy inspector frontend by using `window.open()` from the test page, and establishes bidirectional communication with the __child__ inspector page using `window.postMessage` and a `message` event handler. The "inspector" page that is loaded into the iframe is located at `Source/WebInspectorUI/Base/TestStub.html`. The code that runs inside the Inspector frame (i.e., code within the test() method) has access to the protocol test harness, whose methods are prefixed with `ProtocolTest`. Protocol-specific methods for sending commands and awaiting on events are available in the InspectorProtocol namespace. |
