On Sat, Nov 14, 2009 at 2:39 PM, Phlip <[email protected]> wrote: > The answer: > > While all tests should use the transaction-rollback trick, and it > seems the sqlite3 handlers don't use it... > > ...the primary culprit turned out to be this: > > fixtures = ['countries'] > > Even though the tests run in an app with a fixture with a very short > list of sample countries & regions... > > ...another app, higher up the food chain, has a "fixture" that > contains all the database prep, with all the countries, designed to be > loaded only once. > > The fix is of course renaming the shorter json file: > > fixtures = ['short_countries'] > > This problem represents two minor oversights in Django's architecture: > > Firstly, the original meaning of a "fixture" was _behavior_ shared by > test cases. assertEqual() was a fixture, as was assertInvoiceGotMailed > (). The first is generic and the second application-specific. Ruby on > Rails stretched this definition by referring to the model objects > available to tests as fixtures - that was a mistake. Database objects > were supposed to be called "resources", in the original Smalltalk > mileux. Enough said, and nobody's making a Federal case out of it.
I won't claim to be a Smalltalk expert, that this certainly isn't the common usage of fixture these days. >From [1] "In generic xUnit, a test fixture is all the things that must be in place in order to run a test and expect a particular outcome". [1] http://en.wikipedia.org/wiki/Test_fixture You can do this manually with setUp(), but given that Django apps tend to be data centric, we provide a handy syntax for loading data, which will form a big part of any setup process. > Nextly, the lookup for fixtures=[] should start in the current app. > Django intends to be testable and modular, but your tests should not > all break just because you suddenly plugged in a new module that came > with a fixture that preempted your fixture. Fixtures don't pre-empt anything. Django fixtures just exploit the behaviour of loaddata. "loaddata foo" is clearly documented to load _all_ fixtures named 'foo' from _all_ applications in a project. This is by design, and it allows us to do nifty tricks, like automatically installing initial data by naming your fixture initial_data - the name is automatically found as part of the loaddata call that is made by syncdb. The obvious corollary of this is that if you use a common name for your fixture, you could end up with unexpected data in your database. The solution - don't use common names for your fixtures, and pay close attention to the number of objects reported output when you load fixtures. Analgous problems exists in many places in Django - for example, you can't just name a URL 'logout' and expect that it won't clash with URLs from other apps. When naming things in a Django project or app, using unambigous names is just part of being a good Django citizen. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. 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=.
