11

Or, "How to design your Database Schema for easy Unit testing?"

By the way, there is a very similar question to this here: How to test Models in Django with Foreign Keys

I'm trying to follow TDD methodology for a project that uses the framework Django. I'm creating and testing models and its functionality (save methods, signals,...) and other high level functions that relies on the models.

I understand that unit testing must be as isolated as possible but I find myself creating a lot of tables and relations using FactoryBoy for each test, so my test is not strong enough because if something changes in a model many tests could be broken.

How to avoid all these dependencies and make the test cleaner?

What do you guys recommend to avoid all that boilerplate before the actual test?

What are the best practices?

Community
  • 1
  • 1
javier
  • 1,705
  • 2
  • 18
  • 24
  • @dm03514 by high level function i mean functions that run some statistical calculations over the data, but that's not the problem, the problem is that the table this functions uses has a lot of relations of all kinds (one-to-many, many-to-many, etc) so it's a pain to have to create instances for all that models just to test some function – javier Aug 09 '12 at 14:26
  • @dm03514 about the answer you deleted:Thanks for your answer and for the link to pyramid =); I think that probably I would change my question to how to design the database schema for easy unit testing? what kind of pattern exist?; by the way, fixtures is not a great way to deal with data for testing for that reason I'm using factory boy as I mentioned in the question, see for example: [link]http://lincolnloop.com/blog/2012/may/3/fixtures-and-factories/ – javier Aug 09 '12 at 14:37

3 Answers3

13

There is no list of best practices for testing, it's a lot of what works for you and the particular project you're working on. I agree with pyriku when he says:

You should not design your software basing on how you want to test it

But, I would add that if you have a good and modular software design, it should be easy to test properly.

I've been recently a little into unit testing in my job, and I've found some interesting and useful tools in Python, FactoryBoy is one of those tools, instead of preparing a lot of objects in the setUp() method of your test class, you can just define a factory for each model and generate them in bulk if needed.

You can also try Mocker, it's a library to mock objects and, since in Python everything is an object, you can mock functions too, it is useful if you need a test a function that generates X event at a certain time of the day, for example, send a message at 10:00am, you write a mock of datetime.datetime.now() that always returns '10:00am' and call that function with that mock.

If you also need to test some front-end or your test needs some human interaction (like when doing OAuth against ), you have those forms filled and submitted by using Selenium.

In your case, to prepare objects with relations with FactoryBoy, you can try to overwrite the Factory._prepare() method, let's do it with this simple django model:

class Group(models.Model):
    name = models.CharField(max_length=128)
    members = models.ManyToManyField(User, blank=True, null=True)

    # ...

Now, let's define a simple UserFactory:

class UserFactory(factory.Factory):
    FACTORY_FOR = User

    first_name = 'Foo'
    last_name = factory.Sequence(lambda n: 'Bar%s' % n)
    username = factory.LazzyAttribute(lambda obj: '%s.%s' % (obj.first_name, obj.last_name))

Now, let's say that I want or need that my factory generates groups with 5 members, the GroupFactory should look like this

class GroupFactory(factory.Factory):
    FACTORY_FOR = Group

    name = factory.Sequence(lambda n: 'Test Group %s' % n)

    @classmethod
    def _prepare(cls, create, **kwargs):
        group = super(GroupFactory, cls)._prepare(create, **kwargs)
        for _ in range(5):
            group.members.add(UserFactory())
        return group

Hope this helps, or at least gave you a light. Here I'll leave some links to resources related with the tools I mentioned:

Factory Boy: https://github.com/rbarrois/factory_boy

Mocker: http://niemeyer.net/mocker

Selenium: http://selenium-python.readthedocs.org/en/latest/index.html

And another useful thread about testing:

What are the best practices for testing "different layers" in Django?

Community
  • 1
  • 1
iferminm
  • 2,019
  • 19
  • 34
3

Try to use Mixer. It's much easier than 'factory_boy' and is much more powerful. You don't need to setup factories and you get data when you need them:

from mixer.backend.django import mixer

mixer.blend(MyModel)
sgrif
  • 3,702
  • 24
  • 30
klen
  • 1,595
  • 12
  • 11
0

I'm not really sure if you need to go that deep. You should not design your software basing on how you want to test it, you need to adapt your way of testing to the tools you're using.

Say that you want to get that level of granularity, like mocking FK and M2M models when you test some model, right? Something like

class Invoice(models.Model):
    client = models.ForeignKey(Client)

and in your tests, you want to test only Invoice model, without dealing with Client model. Is that right? So, why don't you mock the database backend too, and just test ONLY what your model should do?

My point is that you don't need to get to that level. Add some tests to your models for non-trivial things like signals, methods, check that the model creations are working (can even avoid this if you trust the database), and when you need to work with external models just create what you need on the test's setUp() method.

Also if you want you can mock whatever you want using Python's mock library: http://www.voidspace.org.uk/python/mock/. If you really want to do TDD, you can use it for mock your FK in each test, but if you change that model, you will need to change all the mockers too.

pyriku
  • 1,251
  • 7
  • 17
  • Yes, you are probably right I'm going too far; for the moment I'm exploring [factory boy](https://github.com/dnerdy/factory_boy) and [model mommy](https://github.com/vandersonmota/model_mommy) and I think this is just what I was looking for( for the moment, but always is room for improvement) – javier Aug 09 '12 at 20:25