Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
#12991 unittest2 support - Second call for comment
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Russell Keith-Magee  
View profile  
 More options Oct 2 2010, 11:27 am
From: Russell Keith-Magee <russ...@keith-magee.com>
Date: Sat, 2 Oct 2010 23:27:29 +0800
Local: Sat, Oct 2 2010 11:27 am
Subject: #12991 unittest2 support - Second call for comment
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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Russell Keith-Magee  
View profile  
 More options Oct 4 2010, 10:11 am
From: Russell Keith-Magee <freakboy3...@gmail.com>
Date: Mon, 4 Oct 2010 07:11:24 -0700 (PDT)
Local: Mon, Oct 4 2010 10:11 am
Subject: Re: #12991 unittest2 support - Second call for comment

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.

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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »