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’”.