Test Driven Development with Django

Question

I have a conceptual question about doing test driven development with Django, may also apply to other frameworks as well.

TDD states that the firts step in the development cycle is to write failing tests.

Suppose for a unit test, I want to verify that an item is actually created when a request arrives. To test this functioanlty, I want to issue a request with the test client, and check with the db that this object is actully created. To be able to do that, I need to import the related model in the test file, but as the first step is writing this test, I don't even have a model yet. So I won't be able to run the tests to see them fail.

What is the suggested approach here? Maybe write a simpler test first, then modify the test after enough level of production code is implemented?

Answer 1

Important note: What you describe is not a unit test. It does not test one unit. It tests whole bunch of things starting form django url wiring, views and ending with models. This is integration tests. Secondly, don't create a test that uses external API (or test client which is mostly the same) to create data but checks that entity was created by going directly to DB. This is not good. If you create data via some API you should use the API of the same level to check the data is created. So my explanation will talk about this approach.

What you describe is a common problem when you start with TDD.

Important things about TDD are that you:

1. do small steps
2. refactor after test is green (including test refactoring)

This may sound like simple and you most probably have read and know that but the consequences for how you structure you work might not be that obvious.

Main consequence is that you do not write the full test from the scratch before implementing the functionality. You start with simplest test you can do, make it work (by implementing some piece of functionality), refactor. Then you change the test by adding more things that you want to check to it, implement that piece to make test green, refactor and so on.

That has consequence that you need to split the work (or plan how you implement it by simple steps) to be able to work in this mode. This requires some practice and I guess is one the main barriers for TDD adoption.

It is similar (but with important difference) to what you wrote:

Maybe write a simpler test first, then modify the test after enough level of production code is implemented?

You need to have simple test first, then modify it iteratively with small steps but before you implement production code not after.

In this particular case you can implement it in following steps:

1 Create the test that uses test client

def test_entity_creation(self):
    post_result = test_client.post(POST_URL, {})

    get_result = test_client.get(get_entity_url_from(post_result))

    assert_that(get_result, not_none())

You have a test that fails but no line of code is written. Note that no data is passed yet and the check is very basic.

2 Create url wiring and empty view

Do it so that the test pass. You need very few changes in the code and the view will not return much if anything. View can return some hardcoded json/dict at this point.

3.1 Check that id of the entity is generated

def test_entity_creation(self):
    post_result = test_client.post(POST_URL, {})

    get_result = test_client.get(get_entity_url_from(post_result))

    assert_that(get_result, not_none())
    assert_that(get_result, has_field('id', not_none()))

You can make this test work by adding id to the hardcoded dict.

3.1 Check that unique id of the entity is generated

Add a new test that checks that ids are unique:

def test_create_generates_unique_id(self):
    post_result1 = test_client.post(POST_URL, {})
    post_result2 = test_client.post(POST_URL, {})

    assert_that(get_id(post_result1), not_(equal_to(get_id(post_result2)))

4 Add the model with only id

It is not hard to add a model with only id and add its creation and retrieval from the view. Don't add all the fields that you need, you will do that step by step later.

5 Add one field to you test

def test_entity_creation(self):
    post_result = test_client.post(POST_URL, {'field': 'value'})

    get_result = test_client.get(get_entity_url_from(post_result))

    assert_that(get_result, not_none())
    assert_that(get_result, has_field('field', 'value'))

Add a field to the model and make the test pass.

6 Continue doing TDD

Add more tests and production code.

Some more thoughts

Step 4 might be too big as for one TDD cycle. It requires making changes at least to three things:

1. post view handler
2. get view handler
3. model

In many cases it makes sense to split it by first creation a test for the model itself. The test that will not work with test client but will look like this:

def test_entity(self):
    entity = Entity.objects.create()

    entity = Entity.objects.get(entity.id)

    assert_that(entity.id, not_none())

Then you add a model. Make sure that test_entity pass and only after that modify view to use you (already tested) model.

I hope this gives the idea how to approach this problem.

Answer 2

In Django, the approach is always to recreate a working environment for testing and staging. In testing the data is fake, in staging the data is "old" or very similar to the production.