So, up until now, most of the work on windmill hasn't exactly been 'tester
ready' in that, if you didn't you my exact incantation of settings, luck,
module versions and love, you didn't get very far. While I still haven't
gotten real docs done (my original plan for the week) I have learned a
valuable lesson in assumptions. I foolishly assumed that splitting the WSGI
handler into its own thread,
while introducing another server (windmill), and doing my fixture
loading in the primary thread would just work. Surprisingly, it almost
does, except for the sqlite3+:memory: instance.
Obviously, as this is how 99% of django tests are run, I had hit a snag. I
believe that the problem is
solved, but it did put me a bit behind, as I have had to totally
reconsider how the loaders and databases
are handled. Namely, the following questions arose:
1. Should windmill tests default to non-isolated/non-transactional DB
behavior? Basically, we are providing the means for functional tests, these
should be tests like 'Register and Complete a Profile', then 'Edit Profile'.
We don't want this as one massive test, and it seems like that would be the
expected behavior most of the time, and still allowing for the option of
specific tests being run in isolation seems like the best move. However,
this could be confusing, or just bad practice, so I wanted to get some
feedback.
2. Scratch my #2 I caught one of the Windmill guys on the IRC and got
some good direction on detection stuff.
3. What is the general interest in test-only models as a public api? The
mechanics of it have been worked out for the regression suite, but the
debate falls to one of the following systems.
1. A class used instead of db.Model (db.TestModel)
2. A module in the app (test_models.py)
3. Similar to fixtures (a property on tests)
4. A settings option
4. I am assuming that code coverage of windmill tests isn't that useful
of a number, given the specialized execution paths etc. But I wanted to
double check that people wouldn't be surprised by that.
Overall, there has been marked improvements in the runner state, and I've
added some more tests as well. However, I am holding off on the really js
intense tests until the framework is rock solid. But I wanted to get moving
on documentation sooner rather than later, so I expect a bit more cleanup
next week to make sure that the elaborate charade we play (conning windmill
to play with us) is reliable for 3rd party applications as well.
The branch isn't really ready for testing yet, but it has been known to
work. And Eric has kindly thrown up a coverage report!
http://media.ericholscher.com/django_coverage/
--
Kevin Kubasik
http://kubasik.net/blog
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
