There are a couple of problems with setting up a big database and then writing integration tests. Your tests will be slow, so they won't get run. They'll also be increasingly hard to maintain. Fixtures only seem make that worse. You've already got a code base that needs maintaining, you don't want to add another one.
BUT you also have the problem that writing nice, isolated unit tests is going to require a lot of refactoring. That's scary because you don't have any tests in place, so you might break something and not know about it. I would approach it like this: 1) Decide on one functional area or workflow that you want to start with. Preferably, this would be (relatively) self-contained. 2) Create the fixtures you need for testing that area. 3) Write some high-level integration tests that cover all the important workflows for your user. I'd use the built in test client or WebTest for this. 4) Start writing real unit tests for the code in this area. Where necessary use factory_boy to set up your models, rather than fixtures. Mock your external dependencies. You will almost certainly have to do a lot of refactoring in order to write good, isolated unit tests. But you now have some confidence that you're not breaking things because of the high level integration tests. 5) Once you've achieved some good coverage with your unit tests, either start on a new area or refactor your integration tests. Get rid of the fixtures and move to factory_boy. Make sure you're testing the minimum necessary at this level, because they'll be your slowest and most fragile tests. There's an excellent presentation by Carl Meyer that covers some tools and approaches to write better tests: http://pycon-2012-notes.readthedocs.org/en/latest/testing_and_django.html Hope that helps. Josh On Friday, 5 October 2012 01:49:19 UTC+8, Daniele Procida wrote: > > I have started writing my first tests, for a project that has become > pretty large (several thousand lines of source code). > > What needs the most testing - where most of the bugs or incorrect appear > emerge - are the very complex interactions between objects in the system. > > To me, the intuitive way of testing would be this: > > * to set up all the objects, in effect creating a complete working > database > * run all the tests on this database > > That's pretty much the way I test things without automated tests: is the > output of the system, running a huge database of objects, correct? > > However, I keep reading that I should isolate all my tests. So I have had > a go at creating tests that do that, but it can mean setting up a dozen > objects sometimes for a single tiny test, then doing exactly the same thing > with one small difference for another test. > > Often I have to run save() on these objects, because otherwise tests that > depend on many-to-many and other database relations won't work. > > That seems very inefficient, to create a succession of complex and > nearly-identical test conditions for dozens if not hundreds of tests. > > I'd appreciate any advice. > > Daniele > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Tz7_T4pZfTgJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
