Runningtests

Different settings

To run tests with different settings that normal you need to override the --settings option like this for example:

./manage.py test --settings=settings.local_test homepage

Remember, Django always makes sure tests are run with DEBUG=False so that's something you can't change in your local test settings file. Here's a suggestion for what you can put in your settings/local_test.py file:

from settings import *
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': ':memory:',
    },
}
TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'

The reason we change the TEST_RUNNER to the standard django_nose test runner is because the base test runner, called test_utils.runner.RadicalTestSuiteRunner, is specifically for MySQL so it can't be used when using sqlite3.

Running individual test cases or individual tests

When doing test-driven development it helps to be able to run individual tests over and over. Here's how with nosetests (which finds the tests for Django to run)

# Run a specific file
./manage.py test tinder.tests

# Run a specific test case class
./manage.py test tinder.tests:ViewsTestCase

# Run a specific test method in a test case
./manage.py test tinder.tests:ViewsTestCase.test_showlog

The magic colon is before the TestCase class, so in the case of shipping, you'd call

# Run a testcase in shipping
./manage.py test shipping.tests.test_api:ApiActionTest.test_count

Getting to pdb

Run the tests via

# disable output capturing for pdb
./manage.py test -s

Running tests over and over

The optimal way to develop is to run tests, as fast as possible, as soon as possible. To do that,

1. Make sure you have a local test settings file that uses sqlite
2. Use the nosetests syntax to run an individual test method
3. Use kicker (or something equivalent) to monitor file changes and immediately execute the test run

(kicker is a Ruby gem you install with gem install kicker)

kicker -e 'FORCE_DB=1 ./manage.py test --settings=settings.local_test tinder.tests:ViewsTestCase.test_showlog' apps/tinder/

That tells kicker to execute the tests whenever any file inside apps/tinder/ is saved. The FORCE_DB=1 is necessary because when using sqlite's ::memory:: database the tables need to be created every time.

Coverage testing

To check code coverage you first of all need to have coverage installed. Then, to test coverage on a single apps it might look like this:

$ coverage run --source=apps/mbdb ./manage.py test && coverage html

That will give you a summary of the coverage which you can open in Firefox like this:

$ open cover/index.html