Automated testing

This is a page about improving or modifying OpenHatch.

We call that "Hacking OpenHatch," and there is a whole category of pages about that.

The purpose of this page is to show you how to write an automated test within the OpenHatch codebase.

If you already know how software testing works, skip to A quick tutorial.

Tests: An overview

You really should write a test if you add new functionality. That way, you can run:

./bin/mysite test base missions account profile

and you'll see a

dot dot dot

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):
        # Make a dictionary that should return 1
        self.assertEqual(35,
                         mysite.base.views.multiply(7, 5))

Read the official Django testing guide

The official guide on Django testing is quite good. It says:

The best part is, it's really easy.

We use the Django "unit test" style of writing tests.

• Go read the official Django testing guide.

How to write code that is easy to test

Here are some tips on making code easy to test:

• If you are writing a function, make it accept arguments for its data, rather 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

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

In mysite/base/tests.py

About fixtures

If you inherit from TwillTests, you get some data in your database. You can rely on it.

To run your tests

What app did you write your test in? Let's pretend it was in base:

./bin/mysite test base

To run your tests quickly

The normal test runner uses MySQL, and has to do a bunch of database setup and teardown. If you want the tests to run faster, you can use a different settings file that uses an in-memory SQLite database.

./bin/sqlite_mysite test base

The tests will run about five times faster that way.

To run just a few specific tests

./bin/sqlite_mysite test base.Feed base.Unsubscribe.test_unsubscribe_view

The structure here is app.class.method. So if you want to just run your own new test, you can do it that way.

Mocking, patching, and TwillTests

This section is important, but we haven't written it yet. Oops.