Testing and writing tests¶
Zulip has a full test suite that includes many components. The most important components are documented in depth in their own sections:
- Django: backend Python tests
- Casper: end-to-end UI tests
- Node: unit tests for JS front end code
This document covers more general testing issues, such as how to run the entire test suite, how to troubleshoot database issues, how to manually test the front end, and how to plan for the future upgrade to Python3.
We also document how to manually test the app.
Zulip tests must be run inside a Zulip development environment; if you’re using Vagrant, you will need to enter the Vagrant environment before running the tests:
vagrant ssh cd /srv/zulip
Then, to run the full Zulip test suite, do this:
This runs the linter (
tools/lint-all) plus all of our test suites;
they can all be run separately (just read
tools/test-all to see
them). You can also run individual tests which can save you a lot of
time debugging a test failure, e.g.:
./tools/lint-all # Runs all the linters in parallel ./tools/test-backend zerver.tests.test_bugdown.BugdownTest.test_inline_youtube ./tools/test-backend BugdownTest # Run `test-backend --help` for more options ./tools/test-js-with-casper 09-navigation.js ./tools/test-js-with-node utils.js
The above setup instructions include the first-time setup of test databases, but you may need to rebuild the test database occasionally if you’re working on new database migrations. To do this, run:
Possible testing issues¶
When running the test suite, if you get an error like this:
sqlalchemy.exc.ProgrammingError: (ProgrammingError) function ts_match_locs_array(unknown, text, tsquery) does not exist LINE 2: ...ECT message_id, flags, subject, rendered_content, ts_match_l... ^
… then you need to install tsearch-extras, described above. Afterwards, re-run the
When building the development environment using Vagrant and the LXC provider, if you encounter permissions errors, you may need to
chown -R 1000:$(whoami) /path/to/zulipon the host before running
vagrant upin order to ensure that the synced directory has the correct owner during provision. This issue will arise if you run
id usernameon the host where
usernameis the user running Vagrant and the output is anything but 1000. This seems to be caused by Vagrant behavior; for more information, see the vagrant-lxc FAQ entry about shared folder permissions.
Schema and initial data changes¶
If you change the database schema or change the initial test data, you
have to regenerate the pristine test database by running
Wiping the test databases¶
You should first try running:
If that fails you should try to do:
sudo -u postgres psql > DROP DATABASE zulip_test; > DROP DATABASE zulip_test_template;
and then run
Recreating the postgres cluster¶
This is irreversible, so do it with care, and never do this anywhere in production.
If your postgres cluster (collection of databases) gets totally trashed permissions-wise, and you can’t otherwise repair it, you can recreate it. On Ubuntu:
sudo pg_dropcluster --stop 9.1 main sudo pg_createcluster --locale=en_US.utf8 --start 9.1 main
Local browser testing (local app + web browser)¶
This section is about troubleshooting your local development environment.
There is a separate manual testing doc that enumerates things you can test as part of manual QA.
Clearing the development database¶
You can use:
to drop the database on your development environment and repopulate your it with the Shakespeare characters and some test messages between them. This is run automatically as part of the development environment setup process, but is occasionally useful when you want to return to a clean state for testing.
- `IterationProfiler`: Profile part of looping constructs (like a for loop or $.each). You mark sections of the iteration body and the IterationProfiler will sum the costs of those sections over all iterations.
Chrome has a very good debugger and inspector in its developer tools. Firebug for Firefox is also pretty good. They both have profilers, but Chrome’s is a sampling profiler while Firebug’s is an instrumenting profiler. Using them both can be helpful because they provide different information.
Python 3 Compatibility¶
Zulip is working on supporting Python 3, and all new code in Zulip
should be Python 2+3 compatible. We have converted most of the codebase
to be compatible with Python 3 using a suite of 2to3 conversion tools
and some manual work. In order to avoid regressions in that
compatibility as we continue to develop new features in Zulip, we have a
tools/check-py3, which checks all code for Python 3
syntactic compatibility by running a subset of the automated migration
tools and checking if they trigger any changes.
tools/check-py3 is run
automatically in Zulip’s Travis CI tests (in the ‘static-analysis’
build) to avoid any regressions, but is not included in
it is quite slow.
tools/check-py3, you need to install the
future Python packages (which are included in
requirements/py3k.txt, which itself is included in
requirements/dev.txt, so you probably already have these packages
check-py3 on just the Python files in a particular directory, you
can change the current working directory (e.g.
cd zerver/) and run
check-py3 from there.
Also, if you’re using Vagrant or if you set up virtualenvs in the non-Vagrant setup, you should have two different virtualenvs: one for Python 2 (which is the one used by default), and another one for Python 3. This is useful if you want to do some manual testing using either version.
To switch between both virtualenvs, run:
- Use Python 2:
- Use Python 3: