| 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. |
| | 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 log test results and to trigger specific inspectable behaviors. |
| | 21 | |
| | 22 | == Protocol Tests |
| | 23 | |
| | 24 | Protocol tests are appropriate for testing inspector features that require the use of a few commands and events between the backend and frontend, and do not require the inspected page to be reloaded. Protocol tests are fairly low-level, and exercise the Inspector backend independent of a particular frontend and its controllers and models. In other words, you cannot test Managers or other classes in the WebInspector namespace using a protocol test. |
| | 25 | |
| | 26 | 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. |
| | 27 | |
| | 28 | == Frontend Tests |
| | 29 | |
| | 30 | Frontend tests exercise the functionality of models and controllers specific to WebInspectorUI (the user interface included in WebKit trunk). They use a real, headless Web Inspector frontend that persists across navigations of the inspected (test) page. |
| | 31 | |
| | 32 | The inspector-test.js stub creates a real (for WebKit2, separate process) inspector frontend. Instead of the normal Web Inspector base page (`Main.html`), it loads a smaller version (`Test.html`) which does not load Views and other code not used by tests. The code that runs inside the Inspector (i.e., code within the test() method) has access to the frontend test harness, whose methods are prefixed with `InspectorTest`. Like ordinary Web Inspector code, injected inspector code has full access to models and controllers in the `WebInspector` namespace. (However, as noted above, not all files are loaded in the test version of the Inspector. You may need to add additional files to `Test.html` when testing new code or adding inter-class dependencies.) |
| | 33 | |
| | 34 | == Manual Tests |
| | 35 | |
| | 36 | A manual test requires manual interaction with a test page to exercise specific behaviors. The test page should describe the necessary interaction steps, and the expected output/behavior. |
| | 37 | |
| | 38 | == Library Tests |
| | 39 | |
| | 40 | TODO |
| | 41 | |
| | 42 | ----- |
| 44 | | 1. The test page is loaded by the test runner. Each test page must include `inspector-test.js`, which sets up the connection to the inspector page and provides other helpers. Its functions are in the namespace `InspectorTestProxy`, to remind you that it proxies calls from the test page to the inspector page. |
| 45 | | 2. When the test page finishes loading, `runTest()` executes on the test page and asks the test runner to start up the Inspector. The file `Test.js` is loaded by the Inspector and initializes its environment. Functions that execute in the Inspector use the `InspectorTest` namespace. |
| 46 | | 3. When the inspector finishes loading and receives all marshalled code from the test page, it runs the `test()` method __in the inspector page__. |
| 47 | | 4. As the test runs, results are marshalled back to the test page by injecting and eval'ing JavaScript code. |
| | 74 | // Best used in combination with dumpActivityToSystemConsole. |
| | 75 | InspectorBackend.dumpInspectorProtocolMessages = false; |
| | 76 | }}} |
| 51 | | Sometimes it can be hard to debug inspector tests (particularly, model tests) because the mechanisms for marshalling test results to the test page are fragile and can silence parse or other errors. We provide a flag that causes the test harness to synchronously log messages and errors to STDOUT rather than the test page. If your test mysteriously times out, set the flag `InspectorTest.dumpMessagesToConsole` (in `Test.js`) to true to enable this logging. |
| | 80 | {{{ |
| | 81 | $ DYLD_FRAMEWORK_PATH=WebKitBuild/Debug lldb -- WebKitBuild/Debug/DumpRenderTree |
| | 82 | (lldb) run LayoutTests/inspector/dom/focus.html |
| | 83 | }}} |
| | 84 | |
| | 85 | To run DumpRenderTree in "server mode", which the run-webkit-tests uses to run multiple tests without restarting the process, make a file called "tests-to-run.txt" with one test per line, and launch this way instead: |
| | 86 | |
| | 87 | {{{ |
| | 88 | (lldb) process launch -i tests-to-run.txt "-" |
| | 89 | }}} |
| | 90 | |
| | 91 | === Attaching a Debugger to Tests with WebKitTestRunner (WebKit2) |
| | 92 | |
| | 93 | TODO |
