On 20/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
On 12/20/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> Hi Russell,
>
> I've been using Hugo/Georg's stuff.testing [1] framework for quite a
> while and some of the things I like about it are:
>
> a. I can have fixtures located anywhere in my python path and load
> them. I have project wide fixtures that I use for testing some of my
> apps without having to duplicate those fixtures in the app's own test
> directory.
This is what settings.FIXTURES_DIR is for. If you have a source of
useful fixture data that you want multiple applications/projects to
use, put the fixture somewhere accessible and reference the directory
in your settings file.
thanks I missed that.
> b. The fixtures are Python classes and are instantiated and made
> available in the TestCase test methods.
The only thing that would make my life easier is if the fixtures
became attributes of the test case, maybe adding a 'name' field like
so:
{
'pk': '15',
'name': 'Author1',
'fields': {
'name': 'John Smith'
}
}
so that in the test case I could do:
class AuthorCase(TestCase):
fixtures = { 'json': ['fixture1']}
def testSomething(self):
# test something with self.Author1
In Hugo's framework self.Author1 is a dummy object that mirrors to the
real one in the DB with the same attributes set including the id. It
saves quite a bit of boilerplate per test where you would normally
have to go fetch the fixture(s) from the DB and then test something
with them.
>
> Also, how is hooking up related objects handled by your fixtures?
By PK value. For example, a JSON snippet:
{
"pk": "15",
"model": "testproject.author",
"fields": {
"name": "John Smith"
}
},
...
{
"pk": "32",
"model": "testproject.article",
"fields": {
"name": "Fixtures are cool",
"authors": [15, 16],
}
},
Article has an m2m relation on Author; the article JSON instance
references the authors as a list of PK values. All the fixtures are
installed as a single transaction, so as long as there are no dangling
PK references, there should be no problems with circular references,
forward references, etc.
> stuff.testing does it by defining pre_save/post_save methods on the
> fixture which seem far more powerful than simple serialized objects.
This is an interesting approach, but not sure if I'm convinced; Here
are two immediate concerns:
- I take it the pre and post targets exist to get around circular and
pre references? While I can see that this is necessary for a python
class to be able to parse and compile, I don't think it's very elegant
for humans to define. The serialization approach means you can put all
the data regarding Article instance 3 in one place; the class approach
means that the article definition is spread over multiple methods in
the fixture class.
- Using the serialization format allows for a simple 'dumpdb' command,
so you can build your fixtures by using your application, then dump
the contents of the database as a fixture. I don't see that an
analogous approach would be possible (or easy) using a programattic
approach.
That said, one of the initial design considerations for the testing
framework was to provide a good set of default features, but to allow
for easy integration with any other testing framework. If you feel
there is something we can do to make integrating Hugo's fixture
approach with the proposed approach, let me know.
Yours,
Russ Magee %-)
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
