|
|
||
|---|---|---|
| .. | ||
| debugging-intermittents.md | ||
| js-object-tests.md | ||
| mochitest-chrome.md | ||
| mochitest-devtools.md | ||
| node-tests.md | ||
| perfherder-compare-link.png | ||
| perfherder-compare.png | ||
| perfherder-create-gecko-profile.png | ||
| perfherder-damp.png | ||
| perfherder-filter-subtests.png | ||
| perfherder-subtests.png | ||
| performance-tests-damp.md | ||
| performance-tests-overview.md | ||
| README.md | ||
| regression-graph.png | ||
| regression-popup.png | ||
| writing-perf-tests-example.md | ||
| writing-perf-tests-tips.md | ||
| writing-perf-tests.md | ||
| writing-tests.md | ||
| xpcshell.md | ||
Automated tests
When working on a patch for DevTools, there's almost never a reason not to add a new test. If you are fixing a bug, you probably should write a new test to prevent this bug from occurring again. If you're implementing a new feature, you should write new tests to cover the aspects of this new feature.
Ask yourself:
- Are there enough tests for my patch?
- Are they the right types of tests?
We use three suites of tests:
xpcshell: Unit-test style of tests. No browser window, only a JavaScript shell. Mostly testing APIs directly.- Chrome mochitests: Unit-test style of tests, but with a browser window. Mostly testing APIs that interact with the DOM.
- DevTools mochitests: Integration style of tests. Fires up a whole browser window with every test and you can test clicking on buttons, etc.
To run all DevTools tests, regardless of suite type:
./mach test devtools/*
Have a look at the child pages for more specific commands for running only a single suite or single test in a suite.