Code should be written so it can be tested, and then there should be
tests for it.

When adding code to an app, tests should be added in that app that
cover the new functionality. All apps have a tests module where
tests should go. They will be discovered automatically by the test
runner as long as the look like a test.

If you’re expecting reverse to return locales in the URL, use
LocalizingClient instead of the default client for the
TestCase class.

We use “modelmakers” instead of fixtures. Models should have
modelmakers defined in the tests module of the Django app. For
example, forums.tests.document is the modelmaker for
forums.Models.Document class.

Unless the current behavior, and thus the test that verifies that
behavior is correct, is demonstrably wrong, don’t change tests. Tests
may be refactored as long as its clear that the result is the same.

Mocha tests are discovered using the pattern
kitsune/*/static/*/js/tests/**/*.js. That means that any app can
have a tests directory in its JavaScript directory, and the files in
there will all be considered test files. Files that don’t define tests
won’t cause issues, so it is safe to put testing utilities in these
directories as well.

Here are a few tips for writing tests:

Any HTML required for your test should be added by the tests or a
beforeEach function in that test suite. React is useful for this.

You can use sinon to mock out parts of libraries or functions under
test. This is useful for testing AJAX.

The tests run in a Node.js environment. A browser environment can be
simulated using jsdom. Specifically, mocha-jsdom is useful to
set up and tear down the simulated environment.

Follow the steps in the installation docs,
including the test dependencies to make sure you have everything you need to
run the tests. If you’re running the tests against a deployed environment then
there’s no need to install anything other than
Tox.

Some of the tests require logging in as a administrator, and others require
logging in as a user. To run these tests you will need to create accounts in
the target environment. If you’re running against a local instance of the
application you can create these users by running the following script:

$ ./manage.py shell < ./scripts/create_user_and_superuser.py

If you want to run the tests that require administrator access against a
deployed instance, then you will need to ask someone on IRC to upgrade one of
your test accounts.

The credentials associated with the test users are stored in a JSON file, which
we then pass to the tests via the command line. If you used the above mentioned
script, then these users are stored in /scripts/travis/variables.json. The
variables file needs to be referenced on the command line when running the
tests.

The following is an example JSON file with the values missing. You can use this
as a template:

Alternatively, if you run the mobile tests in Firefox the user agent will be
changed to masquerade as a mobile browser.

The pytest plugin that we use for running tests has a number of advanced
command line options available. To see the options available, run
pytest--help. The full documentation for the plugin can be found
here.