WebkitLayoutTest theory part 1 + in-depth analysis part 2 layouttest:

Original article: blog. csdn. netyajun0601articledetails8887332 when I started WebKit development, I was curious about how to test this playtool. As a Web developer, I know the number of bugs in the browser rendering engine (although the situation is good now) and the increasingly complex web pages for browsing.

Http://blog.csdn.net/yajun0601/article/details/8887332 when I started WebKit development, one thing I was curious about was how to test it. As a Web developer, I know the number of bugs in the browser rendering engine (although the situation is good now) and the increasingly complex web pages for browsing.

Original article:

Http://blog.csdn.net/yajun0601/article/details/8887332

When I started WebKit development, one thing I was curious about was how this playtool was tested. As a Web developer, I know the number of bugs in the browser rendering engine (although the situation is good now) and the challenges that the increasingly complex web pages bring to the browser engine. Working with bugs for years is naturally something to be avoided, so it is critical to enforce compliance with regulations and avoid regressing.

The WebKit solution is layout tests. In the simplest aspect, layout tests is a bunch of simple web pages (the simpler the better) and expected rendering results files (golden files) submitted to the WebKit source code library ), there are texts and images. Run-webkit-tests uses an embedded WebKit application (DumpRenderTree) to traverse test cases (more than 30000 ), then compare the rendering results and expected results (golden files) of these test cases, and finally generate reports for failures, crashes, timeouts, and other results that are inconsistent with expectations. In the WebKit project, there are compilers that allow layout test to run continuously on all the platforms that have been migrated, so that you can easily find the problematic changes (rollback once discovered ).

Developers are encouraged to run layout tests before submitting code. The simplest way is to use commit queue, which will automatically complete the test execution. If this is not the case, it is also feasible to run all the test cases on the workstation. It takes about 15 minutes to run the test case once, if Dirk Pranke is used, the multi-process test runner time can be reduced to about 4 minutes or less.
Through reasonable use of test data, layout tests can be used to verify many things, from the JavaScript engine standard consistency to the implementation of repainting and WebSocket protocol. If the latter needs to access the network, the test script starts a local server (Apache, lighthttpd, or WebSocket) and then runs the test on the server. The local HTTP server is also useful for simulating network boundary conditions. What makes me laugh is that in the past six months of WebKit work, I was forced to learn and use more PHP than I used Web development in the past six years.

For relatively simple tests, they adopt more unit tests (such as assertions). There is an auxiliary framework that makes such tests easy to build. The expected result file contains a "success" description.

Considering that layout test not only tests rendering and layout, but also includes unit tests of JavaScript bindings, interactive tests of network stacks, and performance tests of magnitude, we will occasionally discuss that the name "layout test" is becoming increasingly inaccurate. Due to this flexibility, the layout test model also performs well when introducing a third-party test suite. As part of layout test, we also run Sputnik JavaScript consistency suite, Philip Taylor's canvas suite, HTML5 parsing suite, and more test cases from other browser vendors.

The next article will discuss some practical things of the layout test system. To learn more, please go to the WebKit wiki.

========================================================== ========================================================== ==================

In-depth analysis of WebKit Layout Tests

There is no special organization to share the knowledge points in the PPT sorting process.

Layout Test main process:

Run the following command:

Run-webkit-tests [Option]Test script file or directory
The main parameters are:

-- Verbose displays detailed information

-- No-build do not try to recompile dumprendertree

-- Debug uses the Debug version for testing

-- Help: display all options

0. Test Method Induction

I. static testing (the test result is determined by comparing the final webpage output .)

Four detection methods:

Render tree, Body Text, Pixel Data, Ref Test

(Body Text has no format information, while Pixel Data does not have Text information. Therefore, the two are used in combination, mainly Body Text .)

Ref Test is compared in the form of HTML pages.Unmatched results are stored as images.

Ii. Dynamic Testing (the test results are dynamically determined during execution. But still output to the webpage,It is reported through static testing .)

The dynamic testing method is the same as static testing.The difference is that the comparison content is already the test result.That is, the JavaScript script has root test conditions and data,The test is successful or fails. Then, the static test mechanism outputs the results.

Composition of test cases:

A. HTML files used for testing (must be in the LayoutTests directory)

Export testname).html

B. Baseline)

. Export testnameapps-expected.txt-> Body Text

. Export testnameapps-expected.png-> Pixel Test

. Export testnameapps-expected.html-> Ref Test

. {Testname}-expected-mismatch.Html-> Ref Test

C. Description

.MissmatchType test onlyRef TestSupported

. Ref TestIs exclusive, if the currentCaseYesRef Test,No other content will be detected.

* For Audio comparison, the content in the script is not analyzed.

* During the first test, there was no comparison standard,LayoutTest automatically generates xxx-expected.Txt or xxxx-expected.png.

* All tested webpages must be placed in the LayoutTests directory.

1. Do not output a date or time in the webpage.

(Dynamic content cannot be compared)

2. The entire Test Case running time cannot exceed 30 s. For details, see another article.

3. js-test-re.js (used with js-test-post.js) defines several result validation functions, such as shouldBeTrue.

For example: