Advanced testing¶
Note
Twill is going away in the OpenHatch code base and is being replaced by WebTest (yay!).
The purpose of this page is to show you how to write automated tests within the OpenHatch codebase.
If you already know how software testing works, skip to the section Details specific to OpenHatch.
Tests: An overview¶
You can run the many tests that are part of the OpenHatch code:
$ python manage.py test
During the test run, you’ll see a bunch of dots. Dots mean success.
- Tip You really should write a test if you add new functionality.
- This page explains how and when to write new tests and how to run the tests we have.
What a basic test looks like¶
Imagine this is in mysite/base/views.py
:
def multiply(x, y):
return x * y
Then this would be in mysite/base/tests.py
:
import mysite.base.views
class TestMultiplication(django.test.TestCase):
def test_return_one(self):
self.assertEqual(35, mysite.base.views.multiply(7, 5))
When a test fails¶
When a test fails you will see:
- FAILED followed by the test_name
- the Traceback
- the failure summary (e.g. FAILED (failures=2, errors=1, skipped=9))
To force a failure, maybe you are just curious to see what it will look like, you can add to the test code:
self.assertTrue(False)
This assertion will fail and so will the test containing this code.
General testing tips¶
Read the official Django testing guide¶
The official guide on Django testing is quite good. It says:
The best part [about writing tests for Django code] is, it’s really easy.
OpenHatch contributors use the Django “unit test” style of writing tests.
How to write code that is easy to test¶
If you are writing a function, have it “accept arguments” for its data, rather than having it calculate the input itself. For example:
Good:
def multiply(x, y):
return x * y
Less good:
def multiply(x):
y = settings.MULTIPLICATION_FACTOR
return x * y
It’s okay to rely on things like system settings and database content, but in general if your functions are simpler, they are easier to test.
Details specific to OpenHatch¶
We regularly run Automated Testing¶
OpenHatch’s Automated Testing is run by Jenkins, with the interface on the virtual machine donated by GPLHost @ http://vm3.openhatch.org:8080/
Where to write your tests¶
In general, add tests to the same Django app as you are editing. For example, if you made changes to base/views.py, then add a test in base/tests.py.
The test files are kind of ‘sprawling’. It doesn’t really matter where within the tests.py file you add your test. I would suggest adding it to the end of the file.
The OpenHatch test case helper class¶
Note
Twill is going away in the OpenHatch code base and is being replaced by WebTest (yay!).
In mysite/base/tests.py there is a TwillTests class. It offers the following convenience methods:
- login_with_client
- login_with_twill
The subversion missions test cases¶
When running or testing the subversion mission locally, subversion (svn and svnadmin) must be installed on the local system. If subversion is not installed, the tests will not be run.
Settings information related to subversion, such as path locations, can be found in the settings.py.
About fixtures¶
Note
Twill is going away in the OpenHatch code base and is being replaced by WebTest (yay!).
To run your tests¶
What Django app did you write your test in? Let’s pretend it was in the
base
module. To run all the tests in base
:
$ python manage.py test base
To run just a few specific tests¶
You can run just one test. For example, a test named base.Feed:
$ python manage.py test base.Feed
Or you can run two (or more) tests:
$ python manage.py test base.Feed base.Unsubscribe.test_unsubscribe_view
The structure here is app.class.method. If you want to just run your own new test, you can do so.
Mocking and patching¶
Note
This section is important, but we haven’t written it yet. Please consider helping us write this section. See Documentation
Testing with Twill, versus the Django test client¶
Note
Twill is going away in the OpenHatch code base and is being replaced by WebTest (yay!).
To make a long story short:
- The Django test client is good at introspecting how the function worked internally.
- Twill tests are good because they let you say “Click on the link called ‘log in’”.