A couple weeks ago, Jeena wrote a post about How to implement a new DOM API for Servo, in which she presented the shiny new Doge API. In this post, the ✨Doge✨ epic continues. Now that we’ve written the Rust code for Servo’s Doge API, we should test that it works as expected.
When Jeena and I worked on Servo over the summer, most of the tests were already written for us as a standard set of web-platform-tests which are used by all of the major browser developers. Similarly, here we’re assuming that the Doge API tests have already been provided for us. If you’re interested in how to make test files, there is some helpful information on the Servo github.
The Doge API has a constructor, an
append() function, and a
Tests are expected to fail prior to implementation
Let’s run the tests!
Here’s what we get if we run the
doge_basic.html tests without implementing the Doge API:
By looking at the output above, it looks like all the tests worked “as expected”.
This doesn’t necessarily mean the tests passed, however.
➟ If we look in the corresponding
doge_basic.html.ini file, we can see the test expectations:
As you can see, there is a
FAIL expectation for each of the corresponding tests in
This means that Servo’s testing framework can run a large number of tests without printing information about failed tests that developers might not be interested in at the moment.
As features get added, the test expectations can be updated, as we’ll see below.
Updating test expectations after implementation
Here’s what we get if we run the tests after implementing the Doge API and re-building Servo:
Thanks to the
--log-raw option when we ran the Doge tests, the test results got stored in
/tmp/servo.log. This can be used to update the expected test results with the following command:
Then if you try to look in
doge_basic.html.ini, you’ll see this:
Instead of replacing each
FAIL with a
PASS, the file was removed. If there are no explicit test expectations in the
.ini file, the default expectation is
Now when we run the tests, everything passes and there are no unexpected test results.
That wasn’t too bad! :)
Up until now we just tested one file by specifying the full path to
doge-basic.html. For things like pull requests, Servo’s continuous integration bot only runs the tests specified as
skip: false in the file
So we’ll set the
[doge] folder to
false so it isn’t skipped during automatic testing.
Another thing that will save both us and the reviewer time is to run
./mach test-tidy before each commit. It checks for minor things like trailing whitespace and Rust
use statements that are not in alphabetical order.
That’s it for now! This workflow is pretty much the one that we (Jeena and I) followed over and over again.
We still feel like we have a long way to go before understanding all the intricacies of the Servo codebase, but we’ve been able to make substantial contributions just by knowing a few key commands. Once again, our journey would not have been possible without the help of all the friendly people on github and the Servo and Rust IRC channels. So, please reach out to them for ideas and debugging help if you’re stuck.
Doge photo: http://kabosu112.exblog.jp/23078463/