On Oct 2, 11:27 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> Hi all,
>
> I've just uploaded a second alpha of the patch introducing unittest2
> into Django's core [1]. As with last time, help is requested running
> the test suite on different Python versions and different databases.
> Particular attention is needed for the Oracle and GeoDjango changes,
> as I don't have the facilities to test these locally. If you have
> access to these setups and can run the suite with the patch applied,
> I'd be very grateful.
>
> [1]http://code.djangoproject.com/ticket/12991
>
> Here's a summary of the changes since last time:
>
> * I've replaced all the checks (including the doctest checks) that
> inspected for a database backend with checks for the database feature
> that is necessary in order to pass the particular test. i.e., instead
> of just checking "backend == MySQL", the tests now checks for
> "connection.features.supports_transactions" or
> "connection.features.supports_timezones". As a result,
> DatabaseFeatures has 18 extra feature flags.
>
> * There are three exceptions to the previous point, all contained in
> the backends regression test. These are tests for Oracle specific
> features that really are checking for Oracle specific features (cursor
> properties, NCLOB behavior, etc). To accommodate this, I've added a
> 'vendor' attribute to connection. This is a lowercase text description
> describing the vendor that has provided the database. This also allows
> us to identify the postgresql and postgresql_psycopg2 backends as
> being from the same vendor.
>
> * As a result of the previous two points, I've been able to remove
> the skipUnlessDB and skipIfDB utilities in favor of just using the
> default unittest skipIf and skipUnless.
After some additional testing, I discovered a slight problem with this
approach. skipIf and skipUnless are evaluated at time of class load,
which is before the test database is set up, so the tests to be
skipped are determined before we know whether they can be skipped.
To counter this, I've reintroduced some custom Django skipIf/
skipUnless functions -- this time, specifically checking the name of
the database feature at runtime.
@skipUnlessDBFeature('supports_transactions') will skip a test unless
the test database supports transactions.
> * Some database features (such as the availability of transactions)
> need to be determined at runtime. To support this, DatabaseFeatures
> has gained a 'confirm()' call. This call does the
> 'SUPPORTS_TRANSACTIONS' check, plus any other check of
> database-specific behavior that needs to be performed at runtime. At
> the moment, the only other case that requires confirmation is STDDEV,
> which may not be available depending on the version of PostgreSQL or
> the extensions loaded into SQLite. The call to confirm() is performed
> as part of the test database setup.
>
> * The SUPPORTS_TRANSACTIONS flag has been moved out of settings, and
> into DatabaseFeatures
>
> * In order to support confirm(), DatabaseFeatures now requires an
> argument at time of construction (the connection).
>
> * I've rolled back the changes that rename the use of deprecated test
> methods like assertEquals, failUnless etc. It occurred to me that this
> patch is only going to be applied to trunk, not to the 1.2 branch, and
> changing the assertion syntax on a large proportion of test cases will
> make backporting tests a major pain. Normalizing test assertion usage
> is still worthwhile, IMHO; it's just something we need to do just
> before we roll 1.3, rather than right now.
As a result of extra testing I have now done myself, I'm ready to call
this an RC patch. Again, help is requested in running this test suite
on as many databases, Python versions and GIS backends as possible.
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 django-develop...@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.
