Django Test framework commits (r3658-r3661)

[Russell Keith-Magee]

Hi all,

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.

As always, comments/suggestions are welcome

Yours,
Russ Magee %-)

[Russell Keith-Magee]

Hi again,

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.

Apologies for any inconvenience.

Yours,
Russ Magee %-)

[d...@simon.net.nz]

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)).

Cheers,
Simon

[1] http://code.djangoproject.com/ticket/2490

[Malcolm Tredinnick]

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.

Regards,
Malcolm

[d...@simon.net.nz]

Malcolm,

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().

Specifically:

(many_to_one:)
Reporter.objects.filter(article__headline__startswith='This').distinct().count()

(many_to_many:)
Article.objects.filter(publications__title__startswith="Science").distinct().count()

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]

[1] http://initd.org/tracker/pysqlite/ticket/173

--Simon