On 01/17/2012 01:04 PM, Thomas Guettler wrote:
Hi,
same subject, but different content:
we have a lot of tests which are read only. They don't modify the database or
other files.
You don't need to flush the database for every test of read only test cases.
These tests can be run on production
servers, too.
At the moment, this unittest code is non public. But if there is any interest,
we
could make it public.
Is anyone interested?
Me at least. Running Selenium tests with the current implementation
(based on TransactionTestCase) is somewhat slow, as the whole DB needs a
to be flushed between each test. More so if you happen to have some
codes you need to have in the DB. A readonly-test would be a big
performance bonus in this case.
Is it possible to write read-only tests in a way that no-modifications
are actually enforced? Maybe that is not wanted. For example, writes to
session table are OK assuming your test starts by new login every time.
It would be possible to implement an API: "read-only, except for these
models" but now this is beginning to get pretty complex...
It is also notable that if "flush only modified" was implemented in
as-fast-as-possible way there would not be much need for read-only test
from performance point. If you have changed nothing, nothing will get
flushed. The main problem here are fixtures: these modify the database
for each test, and thus they need to be reloaded for each test. I have
done some investigating to find a nice way to reload fixtures only when
the data has changed. I haven't found anything nice yet, especially not
for normal Django TestCases, which do the fixture loading inside
transaction which will be rolled back after each test.
If there was a generic "model modified" signal, or something like that,
it would make it possible to easily implement both "flush only modified"
and force "read-only" for tests. Now, I don't know if we want yet
another signal for this. But something like that would be needed. The
implementation used for no.5 upthread is not even closely acceptable for
inclusion.
Now, my biggest concern about "flush only modified" and read-only tests
are that they make the test runner much more complicated and especially
increase the risk of cross-test failures. These errors are generally
hard to debug. The numbers 1-4 do not have this problem.
Maybe the best approach here would be to introduce the needed hooks into
Django core, and then implement the read-only tests and flush only
modified tests as external projects. If they are successful, then
include them in Django core.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
