#12991 unittest2 support - Second call for comment

[Russell Keith-Magee]

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.

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

Yours,
Russ Magee %-)

[Russell Keith-Magee]

On Oct 2, 11:27 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

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