On Tue, May 28, 2013 at 2:26 AM, Anssi Kääriäinen <[email protected]>wrote:
> On 27 touko, 20:15, Shai Berger <[email protected]> wrote: > > On Monday 27 May 2013 19:37:55 Carl Meyer wrote: > > I think a better solution for this is to keep the original method, and > mark it > > with skipUnless(is_core_db) -- we'd need to define is_core_db for that, > of > > course; this could also serve as an easy-to-grep marker for "general > > functionality test, with backend variations" -- which I think would be > quite > > useful for 3rd-party backend writers. > Having vendor checks inside of a test case is painful for non-core backends, but I don't like the approach of entirely skipping these cases because one of the core backends needs to do something different. The existing database features are a bit kludgey, largely due to poor feature naming, inappropriate feature reuse, and sometimes a simple flag doesn't work, but I think that it is still a decent enough solution for the problem of multiple backends. > Traditionally a backend features has been used for this. So, add some > feature like "produces_extra_sql_for_drop_table", if so we skip based > on that. This unfortunately leads to features that make no sense > except when combined with the test suite. Many of the existing features are only used by the test suite, and most of the ones changed by django-mssql only impact testing. Verifying functionality between different databases is less forgiving than simply using the functionality; Most users don't care whether the backend needed 2 or 3 queries to complete the task. > One idea is to somehow include a subclass of problematic test classes > in each backend. The backend can alter or skip those tests that are > backend specific. There are a couple of test apps that should work in > this way (introspection, backends, inspectdb, maybe more). > > I don't know how to make this actually work so that Django's test > runner finds the correct test class from the backend's test module > instead of the generic backends test class. Optimally a backend could > subclass any test class to specialize or skip tests. > django.tests.runtests.setup already has special handling for adding gis test apps. Something similar could be used to for database backends. Not 100% sure what would be a good way of flagging core tests as needing to be skipped or wrapped to expect failure, but we might be able to avoid that issue entirely with a combination of database feature flags and moving the vendor specific problem cases to the respective backends. > For 3rd party backend support in general: My opinion is that we should > include them all in core. The rules would be: > By "them", do you mean 3rd party backend tests or the entire 3rd party backend? Regards, Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
