Setting up proper testing for Django for TDD -

i've been ignoring need test project far long.

so spent more day looking ways implement tests current apps , trying tdd going new apps.

i found lot of "tutorials" steps: "1. install 2. install 3. install thisnthat 4. done!",
noone seems talk how structure tests, both file , code wise.

and noone ever talks how set ci server, or integrate testing deployment of project.
lot of people mention fabric, virtualenv , nose - noone describes how work them whole.

what keep finding detailed information how set proper rails environment testing , ci etc...

does else feel django community lacks in area, or me? :)

oh, , else have suggestions on how it?

as see it, there several parts problem.

one thing need unit tests. primary characteristic of unit tests fast, can test combinatorial possibilities of function inputs , branch coverage. speed, , maintain isolation between tests, if running in parallel, unit tests should not touch database or network or file system. such tests hard write in django projects, because django orm makes convenient scatter database access calls throughout product code. hence tests of django code inevitably hit database. ideally, should approach limiting database access in product code thin data access layer built on top of django orm, exposes methods pertinent application. approach tests mock out orm calls. in worst case, give on this: unit tests become integration tests: hit database, cross multiple layers of architecture, , take minutes run, discourages developers running them enough.

the implication of writing integration tests easy - canonical style of django tests covers perfectly.

the final, , hardest part of problem, running acceptance tests. defining characteristic of acceptance tests invoke application end-to-end, user in production, prove application works. canonical dhango tests using django testrunner fall short of this. not issue http requests (instead, examine url config figure out middleware , view called handle particular request, , call it, in process.) means such tests not testing webserver config, nor javascript, or rendering in browser, etc. test this, need selenium.

additionally, have many server-side processes, such cron jobs, use code our django project. acceptance tests involve these processes should invoke jobs cron does, new process.

both these scenarios have problems. firstly, can't run such tests under django test runner. if try so, find test data have written during test setup (either using django fixtures mechanism, or calling "mymodel().save()" in test) in transaction product code, running in different process, not party to. tests have commit changes make before product code can see them. interferes clean-up between tests django's testrunner helpfully does, have switch different mode, explicit deletes rather rolling back. sadly, slower. @ last night's london django user group, couple of django core developers assured me scenario has other complications (which confess don't know are), best avoid not running acceptance tests within django test runner @ all, creating them stand-alone set of tests.

if this, immediate problem have lost benefits django test runnner provides: namely creates test database, , cleans between each test. have create equivalent mechanism yourself. need product code run against test database if being invoked part of test. need absolutely if product code run part of test, on production box, can never accidentally touch production database, mechanism has absolutely failsafe. forgetting set environment variable in test setup, example, should not cause blooper in regard.

this before considering complications arise deployment, having parts of project in different repos, dependent on each other, creating pip-installable packages, etc.

all in all, i'd love hear feels have found solution problem. far trivial issue commenters imply.