Commit Graph

10 Commits

Author SHA1 Message Date
Umair Khan 740b5634ac Fix and re-enable test-queue-worker-reload.
It seems that we no longer get the message, 'zerver/lib/actions.py
modified; restarting server', but the server reloads successfully
nonetheless.

Fixes: #1341.
2016-08-10 16:17:23 -07:00
Tim Abbott 226a57d2c8 travis: Disable test-queue-worker-reload temporarily.
It's failing nondetermistically pretty often, and I'd like to cut the
impact to other users' work.
2016-07-22 11:36:52 -07:00
Eklavya Sharma e86539649c Use tools/travis/activate-venv in test suites. 2016-07-19 14:15:35 -07:00
rahuldeve 3ca53df152 Add test for worker queue autoreloading. 2016-06-26 20:12:37 -07:00
Tim Abbott 39a8c82957 travis: Remove verbose coverage report from end of build output. 2016-06-15 15:05:38 -07:00
Tim Abbott 062287d0b0 Coveralls: Add coverage reporting to backend test suite. 2016-06-10 17:20:00 -07:00
Umair Khan 938291a922 Add run-dev.py test to Travis CI test suites.
Fixes #919
2016-06-08 14:10:37 +05:00
Tim Abbott 24fd3bbf55 travis: Test whether migrations are consistent with models.
This should automatically catch mistakes where someone updates the
database models but forgets to generate migrations afterwards.
2016-01-26 20:38:46 -08:00
Tim Abbott 9d75fd33d9 Add new test for management commands running with --help.
This test caught a few bugs where refactoring had made management
commands fail (and would have caught a few more recent ones).

Ideally we'd replace this with a more advanced test that actually
tests that the management command do something useful, but it's a
start.
2015-11-11 21:34:39 -08:00
Tim Abbott 6eb670097c Expand testing done via Travis CI to cover production pipeline.
With this change, we are now testing the production static asset
pipeline and installation process in a new testing job (and also run
the frontend/backend tests separately).

This means that changes that break the Zulip static asset pipeline or
production installation process are more likely to fail tests.  The
testing is imperfect in that it does not have proper isolation -- we
build a complete Zulip development environment and then install a
Zulip production environment on top of it, so e.g. any apt
dependencies installed for Zulip development will still be available
for the Zulip production environment.  But, it's better than nothing!

A good v2 of this would be to have the production setup process just
install the minimum stuff needed to run `build-release-tarball` and
then uninstall it / clean it up so that we can do a more clear
production installation, but that's more work.
2015-11-01 18:11:39 -08:00