On 7/12/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
Baited breath, and all that :-)
Initially I was in two minds about allowing tests in models.py. However, I came to the position that allowing tests in models.py hurts nobody, it seems the more natural case for doctests, and tests can always be moved if you end up with a lot of them.
Valid point, and an easy fix. Done
I wondered if someone would pick up on this :-)
When I came up on this, I thought of three options:
1) A TestCase subclass that creates/destroy the db in setup/teardown - DB heavy
2) The test target does creation/destroy - tests are order dependent.
3) A TestCase subclass that overrides run() to do a 'global' setup/teardown - less DB create/destroys, and tests are only order dependent within any given test case. Middle ground solution.
I initially opted for (2) because it is what is already present. However, I will admit a slight personal preference for 1 or 3 (in that order). Having the TestCase subclass handle db creation means that the generic test framework remains generic, so if you need a test class that _doesn't_ need a database backend (or needs a different db backend setup), you can integrate it by writing a different type of testcase extension. To this end, 1 and 3 are not mutally exclusive - we could support both setup strategies in the django test libraries (documenting the differences as appropriate).
However, I acknowledge that these options will impose a big honking performance hit, and I'll agree that this is not necessarily desirable. Although, that said, it shouldn't _really_ matter how long it takes to run the unit test suite, as long as you get a consistent answer that gives you confidence in a modification before taking it live.
I saw it in passing, but haven't played with it yet. Worth keeping in mind though - thanks.
Ok; I'll wait to see what you have to say.
Russ %-)
I'll write up what I was thinking about in another mail; I started to
post it in response to this, but it adds no value to your proposal.
Baited breath, and all that :-)
We are going to see more and more cases of a models/ sub-directory, not
just models.py. So hopefully we can search through those as well
eventually. Putting all models in one file leads to very large files.
On the other hand, I'm pretty unlikely to put my tests in the model
files anyway, since I prefer them in a separate directory (again, to
keep the file sizes manageable). So if I'm being selfish, I don't care
what you do with models.py. :-) However, if I was to be professional
about it, we should maybe consider that case.
Initially I was in two minds about allowing tests in models.py. However, I came to the position that allowing tests in models.py hurts nobody, it seems the more natural case for doctests, and tests can always be moved if you end up with a lot of them.
So you
could just add "test" and it either takes the applications to test as
arguments or nothing (=> test all).
Valid point, and an easy fix. Done
> When a test targets is executed, django-admin:
> 1) creates a test database named 'test_' + settings.DATABASE_NAME
> 2) Installs all the applications in INSTALLED_APPS
> 3) Constructs a test suite from the test cases found in the requested
> apps
> 4) Runs the suite
> 5) Destroys the test database
I wonder how much debate this will cause. :-)
I wondered if someone would pick up on this :-)
This makes the tests order-dependent and possibly hard to run in
isolation. Ideally, flushing and restoring the database between each
test (i.e. it's a part of setup and tearDown, or maybe just a pre- and
post-function on each TestCase-derived class) will keep things "clean".
It will be mean the tests will take ages if you are using a disk-based
database, though.
I don't know if there's a right answer here, or even what the preferred
choice would be.
When I came up on this, I thought of three options:
1) A TestCase subclass that creates/destroy the db in setup/teardown - DB heavy
2) The test target does creation/destroy - tests are order dependent.
3) A TestCase subclass that overrides run() to do a 'global' setup/teardown - less DB create/destroys, and tests are only order dependent within any given test case. Middle ground solution.
I initially opted for (2) because it is what is already present. However, I will admit a slight personal preference for 1 or 3 (in that order). Having the TestCase subclass handle db creation means that the generic test framework remains generic, so if you need a test class that _doesn't_ need a database backend (or needs a different db backend setup), you can integrate it by writing a different type of testcase extension. To this end, 1 and 3 are not mutally exclusive - we could support both setup strategies in the django test libraries (documenting the differences as appropriate).
However, I acknowledge that these options will impose a big honking performance hit, and I'll agree that this is not necessarily desirable. Although, that said, it shouldn't _really_ matter how long it takes to run the unit test suite, as long as you get a consistent answer that gives you confidence in a modification before taking it live.
> Note that at the moment, I'm just looking at getting a basic testing
> framework in place - after that, I will be looking at other problems
> such as:
> - installation of 'fixtures' (YAML/JSON/Python data for testing
> purposes).
If you haven't played with it yet, the "python" serialisation target in
the stuff Jacob recently committed is really useful here.
I saw it in passing, but haven't played with it yet. Worth keeping in mind though - thanks.
> - integration with selenium type tests that require a running server
This is where you start brushing up against the areas I was thinking
about. Although I was looking at it from isolated unit testing
perspectives.
Ok; I'll wait to see what you have to say.
Russ %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
