Revisions 3658-3661 are the commits of the first two phases of the Django Testing Framework.
These changes should have no impact on any existing project. However, should you wish to unit test your Django application, there is now a framework (controlled by ./manage.py test) that will allow you to do so.
In order to eat our own dogfood, the Django internal tests have been migrated to use the new framework. This is changeset 3661. Although this changeset looks large, it isn't actually that complex - it's mostly minor format changes, plus the migration of all the 'othertests' into the 'regressiontests' package.
I am still working on some documentation for these new features. The documentation should be ready some time in the next week. In the meantime, the commentary on ticket #2333, the various django-dev discussions, and the Django internal tests should give you an indication of what is possible, and a vague idea of how to do it.
As I commit, all the unit tests are passing for me; If I've borken anything in the migration, or I've forgotten to 'svn add' a file somewhere, let me know.
This is not the end of the road - there is still more work to be done on the testing framework. The next feature on my list is the implementation of test fixtures.
Following some concerns from Adrian, part of the testing patches have been rolled back (as of r3666). The testing framework itself will continue to work; however, the 'pseudo client' will be unable to inspect template specific details.
FYI I submitted a patch (#2490 [1] ) a while ago to get runtests.py to produce an error if no DJANGO_SETTINGS_MODULE is in the env. Not sure if this is something you want, but I've updated it to work post r3661 - it does make it a little bit easier to work out how to run the tests!
Next - I'm getting failures with an SQLite database on: FAIL: Doctest: modeltests.many_to_many.models.__test__.API_TESTS FAIL: Doctest: modeltests.many_to_one.models.__test__.API_TESTS
Both of these look like they're failing due to SQLite not being able to handle COUNT(DISTINCT(fieldname)).
On Mon, 2006-08-28 at 01:14 -0700, si...@simon.net.nz wrote: > Hi Russ,
> Nice work!
> FYI I submitted a patch (#2490 [1] ) a while ago to get runtests.py to > produce an error if no DJANGO_SETTINGS_MODULE is in the env. Not sure > if this is something you want, but I've updated it to work post r3661 - > it does make it a little bit easier to work out how to run the tests!
> Next - I'm getting failures with an SQLite database on: > FAIL: Doctest: modeltests.many_to_many.models.__test__.API_TESTS > FAIL: Doctest: modeltests.many_to_one.models.__test__.API_TESTS
> Both of these look like they're failing due to SQLite not being able to > handle COUNT(DISTINCT(fieldname)).
Are you running an old SQLite version? My recollection is that SQLite introduced support for count(distinct(...)) about a year ago now. The main distribution I believe is affected are people running old Debian setups (maybe Debian testing is still affected, I don't know). There's an old thread about this on this list. In short, it's a little hard to support the older SQLite versions, because they would end up giving wrong answers for certain queries. We never really resolved it one way or the other, though, so a minimum version number isn't correctly documented.
One SQLite oddity here is that SQLite does not support count(distinct(*)) -- you need to include a column name. Not sure if that is the problem you are seeing or not.
In any case, we have been testing count(distinct(pk_field)) queries for a number of months now as part of the test suite, so if you could check a subversion checkout from before Russell committed his changes and see if the results have actually changed, that would be handy. When I was originally looking over these patches, I tested against SQLite, amongst other things, and saw no failures, so it would be interesting to know what is different on your system if it's something other than an older SQLite installation.
Hmm... ok I was running 3.1.3 on OSX (installed via darwinports). I've upgraded to 3.3.7. Also upgraded pysqlite to the latest in darwinports (2.0.5). But the tests fail for many_to_one and many_to_many whenever .count() is used with .distinct().
So I went and had a play with this, and the query that's generated by Django looks something like:
SELECT COUNT(DISTINCT("tablename"."id")) FROM "tablename"
...which works fine when cut and pasted into SQlite. Tracing it up the stack, Django's not messing this up, it looks like pysqlite is.
Next step - manually upgraded to pysqlite 2.3.2 (the latest), and still doesn't work. It's definitely an issue with pysqlite, & I've submitted a ticket [1]
