Russell Keith-Magee wrote: > > mileux. Enough said, and nobody's making a Federal case out of it. > > I won't claim to be a Smalltalk expert
That's why I said "enough said". C-: The only detail here is I like distinct definitions, and linking "fixture" to "behavior" and "resource" to "data" allows the terms to exploit the most fundamental division in software - the difference between actions and variables. I also like the "all data and behavior needed to run a test case" definition, because it's more comprehensive, and requires fewer polemics! > 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". Right - it's DRY applied to test cases. > 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. What surprised me here is Django uses one fixture system for both the seed data in an application and the ... test fixtures. Naturally, like you said, the fix is discipline to name all test fixtures "test_foo" or something, and to remember to stay out of each others' namespace... -- Phlip -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=.
