Tests are run automatically after every deploy to the Staging server, by the Staging-Tests Jenkins job.

We run automated functional tests through CasperJS, which controls a headless browser so that it can step through the site just like a normal user would (clicking on links, scrolling, reading text, taking screenshots, etc). We use PhantomCSS to run visual regression tests (which take a screenshot of a section of the page, and compare them to an expected output) through CasperJS. We also run client-side unit tests using Mocha.

You can run tests against your local development environment using the ds utility. Running ds test will run our default test suite against your local environment. This is a smart thing to do before submitting a pull request to make sure you don't break the build.

Generally, you want to run the default test configuration. These are the tests that are automatically run after staging deploys, and are configured in tests/config/default.json. You might not want some tests to run all the time, such as testing functionality for an international affiliate. In that case, make an alternate configuration, which can then be run using ds test <configName>.

If you're working on a specific feature, you may not want to run the entire test suite. You can override what tests are run using command line options. For example, ds test --casperjs="user/**/*" will run only the "user" folder of CasperJS tests. You can target a specific test as well: ds test --casperjs="user/login". Note that the test runner will append the appropriate extension for you.

You can see all options available to the test runner by running ds test --help.

Tests are run against the staging database. Make sure you have a recent copy of the database by running ds pull stage before running tests.

If a test fails, all is not lost! Start by looking at the failing test description – did you change anything related to that functionality? You can also see a screenshot of page at the point of the failure in the tmp/tests/screenshots directory, labelled with the timestamp of the failure.

If that doesn't provide enough information, consider enabling the --verbose flag on the test runner. This will give you far more information than you ever wanted to know about exactly what is happening while CasperJS runs your tests, and may provide some more information about what went wrong.