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