On Tue, Jan 6, 2009 at 6:23 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > On Wed, Jan 7, 2009 at 4:51 AM, Todd O'Bryan <toddobr...@gmail.com> wrote: >> >> So, I've been trying to speed up tests. Surprise. I came across a >> fairly easy solution, so I'm sure I must be missing something. If >> someone could tell me what I'm missing, I'd really appreciate it. > ... >> MyTestCaseSubclass.dirties_db = True > ... >> So, what am I missing? I know this doesn't deal with doctests--the db >> gets cleaned for all of those, but does anyone see when this is just >> going to blow up in my face? > > This approach will (clearly) speed up tests. I have three objections > to the technique. > > The first objection is a relatively minor syntactical wart. Using a > normal assignment to set the dirty bit means your test code is mixing > test code with setup code. I'd rather see this sort of thing as a > decorator, so that the test i > I shan't argue with you. It is less than elegant.
> The second objection is more significant: the technique is entirely > manual, and prone to error. If you get all the dirties_db markers > correct, your tests will be much faster; however, if you get one > wrong, you could get all sorts of unexpected consequences, and the > problems won't be reported in the test that actually has the incorrect > dirty marker. The order in which tests doesn't necessarily match the > order in which they are defined in the test case; if you run a subset > of tests, all bets on predictable test output are off. > You're right, of course. But the only thing you can do wrong is mark a test that actually dirties the database as dirties_db = False. Changing the superclass from MyTestCase back to django.test.TestCase should be able to determine if that's the problem. And it's not like writing tests is that easy to begin with. I find that I screw up a significant percentage the first time I write them, so I have to debug my test cases just like I have to debug my code. > The third objection is that in my experience, genuine 0-write test > cases aren't actually that common. This will, of course, vary wildly > depending on your particular project, but I seem to recall looking at > this sort of change and came to the conclusion that it wouldn't > actually speed up the Django test suite that much. Feel free to prove > me wrong. > As I mentioned in the reply to Malcolm, there are some writes that I don't care about. Since it's only within a single TestCase class, I shouldn't need to worry about changes to the session and last_login and such if I know I'm not testing those things. Clearly this requires more thinking than I should have to do, but at this point I'm willing to try the trade-off. I'll probably be back in a few weeks to tell you it wasn't worth it. :-) > There are some plans in place to speed up test cases using > transactions; I'm hoping to be able to look at this once I put the > aggregation and F() code to bed, in the next week or so. > This does sound exciting. I look forward to it. Thanks for the input! Todd --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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=en -~----------~----~----~----~------~----~------~--~---
