On Mon, Nov 29, 2010 at 4:32 AM, Christophe Pettus <x...@thebuild.com> wrote: > Hi, > > I'm updating the patch for #12180 to work with the dev version of 1.3, and > preparing a test case for it. Being new to the Django test suite, it's not > clear to me how to introduce a backend-specific and settings-file-specific > test (the test case requires PostgreSQL 8.2+ and AUTOCOMMIT: True in the > database options). Is there some quick guidance from those more experienced > than me?
As Shai noted, backend specific tests are handled by checking for specific backend features, combined with the use of the @skipIfDBFeature and @skipUnlessDBFeature decorators. The regressiontests/backends directory contains a bunch of examples of how this can be done. Some features need to be detemined at runtime -- for example, the existence of transaction support under MySQL can't be determined until runtime. To support a feature that can't be determined until runtime, you put a hook into the confirm() function on the DatabaseFeatures class for the backend. However, we don't really have a precedent for tests that are dependent on the settings themselves -- i.e., we don't have a test that needs to be run twice (once with setting=True and once with setting=False). Ideally, I'd like to avoid introducing the need to run the test suite once for each possible AUTOCOMMIT setting. One possibility - the tests in the suite all run sequentially, and each test runs with a clean database connection; it might be possible to turn on autocommit for a single test, and then revert the setting later on. 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.
