On Mon, Aug 13, 2007 at 04:31:42PM -0500, Adrian Holovaty wrote: > So I was writing Django view unit tests and setting up fixtures with > sample data, and it hit me -- wouldn't it be useful we made it easy to > run the Django development server with fixture data? > > I'm proposing a "--with-fixture" flag to django-admin.py, so that you > could do something like this: > > django-admin.py runserver --with-fixture=mydata.json > > With this command, Django would: > > * Create a new test database (following the TEST_DATABASE_NAME setting). > > * Import the fixture data into that fresh test database (just as the > unit test framework does). > > * Change the DATABASE_NAME setting in memory to point to the test database. > > * Run the development server, pointing at the test database. > > * Delete the test database when the development server is stopped. > > The main benefit of this feature is that it would let developers poke > around their fixture data and, essentially, walk through unit tests > manually (in a Web browser rather than programatically).
unittests, or doctests? walking through unittests is already viable, docttests, not really (or at least not even remotely pleasant). > In the future, the next step would be to keep track of any database > changes and optionally serialize them back into the fixture when the > server is stopped. This would let people add fixture data through > their Web application itself, whether it's the Django admin site or > something else. Now *that* would be cool and useful! But I'm only > proposing the first part of this for now. That one actually worries me a bit; personally, doctests I view as great for *verifying* documentation, but when used as api tests (as django does), it has two failings imo- 1) doctests are really a pita if you've grown accustomed to the capabilities of normal unittests; further, they grow unwieldly rather quickly- a good example would be regressiontests/forms/tests.py; I challenge anyone to try debugging a failure around line 2500 on that beast; sure, you can try chunking everything leading up to that point, but it still is a collosal pain in the ass to do so when compared to running trial snakeoil.test.test_mappings.FoldingDictTest.testNoPreserver Basically, I'm strongly of the opinion doctests while easy to create, aren't all that useful when something breaks for true assertions; very least, ability to run a specific failing fixture (the above trial command) is damn useful, but not viable with doctests. 2) Adding functionality to automatically collect/serialize a stream of interp. commands, while shiny, is going to result in a lot of redundancy in the tests- I strongly suspect such functionality will result in just building up a boatload of random snippets, many hitting the same code in the same way; while trying to brute force the test source is one way to test for bugs, actual tests written by hand (with an eye on the preexisting tests) is a bit saner imo. Realize django devs take the stance that "doctest/unitest, whatever, it's tests", but not sure if I'd recommend that route. Debugging tool, hey, kick ass; serialization bit, eh, if it scratches your itch... ~harring
pgpNzyF0KieqZ.pgp
Description: PGP signature
