On 12/17/06 11:58 PM, Russell Keith-Magee wrote:
> Time for the long promised phase 3 of the Django testing framework -
> fixtures - to make an appearance. I've attached the changes as a
> single patch to ticket #2333
Rock on, Russ -- this is awesome.
I'm +1 on checking this into trunk right away -- as far as I can tell it's
completely backwards-compatible, right? Unless anyone objects -- and of
course after Adrian's given the OK -- are you happy enough with this to check
it in?
With that said, here's my feedback, in no particular order:
* I'm a big fan of reusing the serialization framework for this. Am I right to
think that adding support for other fixture formats would be as easy as adding
new serialization formats?
* I prefer your "mistaken" syntax for ``django.test.TestCase.fixtures`` (i.e.
a list instead of a dict). It seems that Django could easily derive the format
from the extension, no? Or, you could manually give the extension::
class MyTest(django.test.TestCase):
fixtures = ["foo.xml", "bar.json"]
I kinda like that, one, actually -- explicit is better than implicit.
* I'm fine with JSON being the default fixture format. I have half a YAML
serializer written, but the dependency on Syck makes using it as a default
problematic. Anyone know of a pure-Python YAML library with a license liberal
enough to ship with Django?
* ``dumpdb`` == awesome. We should probably add a "loaddb" command at some
point; that would neatly let people move data from one database engine to
another (i.e. sqlite for testing to postgres for deployment). Nifty.
Actually, now that I think about it, what about naming those functions
"backup" and "restore"?
* I think ``syncdb`` should indeed automatically install some fixture. I'm
not a huge fan of naming it "post_syncdb", but that's OK if we can't come up
with a better name.
* To solve the ``flush`` problem, I'd suggest just adding a method to fall
back on a drop/restore -- that should work anywhere, right?
* I'm +1 on removing ``install`` -- ``syncdb`` should completely replace it.
However, ``reset`` is quite useful in the early stages of designing models;
it's quite useful to be able to drop/recreate an app all at once. Why exactly
would you want to remove it?
* We need some docs written. I'm happy to do it when I get a chance, but it
might take a while. If any lurkers are reading this far down, contributing
some documentation of fixtures as a patch against the testing doc would help
immensely.
And... I'm spent.
Jacob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
