| 1 | Note: This page is a work in progress. |
| 2 | |
| 3 | = Creating a Layout Test = |
| 4 | |
| 5 | == Before creating a test == |
| 6 | |
| 7 | Layout Tests should be added any time new functionality is added to the Rendering system, or any time a bug is found that is not covered by the existing tests. |
| 8 | |
| 9 | Before Creating a new test, always check the platform/Skipped tests to make sure it doesn't already exist. This can be done easily by running {{{run-webkit-tests --skipped=only}}} after compiling with the updated code. |
| 10 | |
| 11 | Any change that breaks currently working tests {{{run-webkit-tests}}} should be considered carefully before proceeding. |
| 12 | |
| 13 | For more information see the documentation on [http://webkit.org/quality/testing.html running tests], [http://webkit.org/quality/testwriting.html writing new tests], and [wiki:"Writing Layout Tests for DumpRenderTree"] |
| 14 | |
| 15 | |
| 16 | == Test with verifiable text results == |
| 17 | |
| 18 | === Guidelines === |
| 19 | |
| 20 | * Keep the test as simple as possible and try to only test what you mean to test. |
| 21 | |
| 22 | === Create the Test === |
| 23 | |
| 24 | * Create the test as a simple HTML page that showcases the bug / new behavior. |
| 25 | * Test should be placed in the appropriate subdirectory under LayoutTests/ use exsiting tests as a guideline or ask on #webkit. |
| 26 | |
| 27 | === Generate Results === |
| 28 | |
| 29 | * Automatically generate results for your by running {{{run-webkit-tests --new-test-results}}}. |
| 30 | * Verify the created results match the desired output. |
| 31 | * If your test is platform independent (results are the same for all platforms) |
| 32 | OR |
| 33 | * If your test applies to Mac and Windows or other platform |
| 34 | * Add the primary results file to the main directory beside the test (all results should be testname-expected.txt) |
| 35 | * If your test has platform dependent results |
| 36 | * Add the results set for the platform you are working on in the corresponding directory the test under the platform/type/ directory. |
| 37 | |
| 38 | === Verify Build === |
| 39 | |
| 40 | Regardless of whether you are making a platform independent change or dependent change, it is your responsibility to ensure that the change does not negatively affect any other ports / platforms. |
| 41 | |
| 42 | Once your change is landed, there are some steps required to verify the change. Note: These steps apply for all changes. If you are making a platform dependent change, should should expect that additional results will be required for each platform but the actions are the same. |
| 43 | |
| 44 | * Arrange to have the patch landed |
| 45 | * Observe the builds with your change at http://build.webkit.org/waterfall |
| 46 | * Any failures will be clearly marked at the top, builds may fail independent of your changes, scrolling down can verify the state of the previously build. |
| 47 | * For each platform the following steps should be followed. |
| 48 | * View the results and verify failure was the new test. |
| 49 | * View the test actual output file for the current behavior. |
| 50 | * If the output is correct |
| 51 | * Add this text to the appropriate platform's directory. (ie, platform/qt/fast/forms/testname-expected.txt) |
| 52 | * If this output is incorrect (or is unclear) |
| 53 | * If you can fix it yourself (ie, compile and test under that platform) do so, otherwise, |
| 54 | * Add the new test to the platforms Skipped file (found at platform/type/Skipped) |
| 55 | * File a bug that details the expected results so that someone else can fix it for that platform and add the results. |
| 56 | * Once all tests / Skipped files have been updated, arrange to have the patch landed with these changes. |
| 57 | * Observe the buildbot again to make sure all tests pass / are skipped and builds are happy. If not, repeat. |
| 58 | |
| 59 | |
| 60 | |
| 61 | == Pixel Tests == |
| 62 | |