On 27 touko, 20:15, Shai Berger <s...@platonix.com> wrote:
> Hi Carl,
>
> On Monday 27 May 2013 19:37:55 Carl Meyer wrote:
>
>
>
>
>
>
>
>
>
> > Hi Shai,
>
> > On 05/27/2013 09:26 AM, Shai Berger wrote:
> > > I'm working on fixing some failing tests under Oracle, and I ran into
>
> > > commands_sql.tests.SQLCommandsTestCase.test_sql_all()
>
> > > [...]
>
> > > For now, I will only special-case Oracle -- that should solve a standing,
> > > release-blocker bug, and not change the semantics of the test otherwise;
> > > but I'd like to achieve something better, more general and
> > > 3rd-party-backend- friendly, for the future.
>
> > It seems to me that ideally a test for backend-specific behavior should
> > become a test for that backend (and thus skipped on other backends).
> > This also solves the third-party-backend problem; said backend should
> > have its own tests as needed, and Django's tests for backend-specific
> > behavior should be skipped under any unrecognized backend.
>
> I agree in general, but this can lead to DRY violations if we're not careful.
> A better example of the problem is a test next to the one I needed to fix:
>
> def test_sql_delete(self):
> app = models.get_app('commands_sql')
> output = sql_delete(app, no_style(), connections[DEFAULT_DB_ALIAS])
> # Oracle produces DROP SEQUENCE and DROP TABLE for this command.
> if connections[DEFAULT_DB_ALIAS].vendor == 'oracle':
> sql = output[1].lower()
> else:
> sql = output[0].lower()
> six.assertRegex(self, sql, r'^drop table .commands_sql_book.*')
>
> Does any backend beside Oracle produce extra SQL for this command? Does the
> different command index for Oracle justify separating this test into two
> separate methods? And if you separate, would you mark the non-oracle case with
> skipIf(Oracle) or with skipUnless(sqlite or postgres or mysql) ?
>
> 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.
>
> Shai.
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.
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.
For 3rd party backend support in general: My opinion is that we should
include them all in core. The rules would be:
1. Core committers do not need to make sure all backends pass tests
before committing features.
2. There are separate committers for the backends, they make sure
that their backend will pass tests eventually.
3. When a release is nearing we will try to make sure each backend
passes tests. If the maintainer of the backend doesn't have time to
fix their backend, then we will try to find a new maintainer. If we
can't find a new maintainer, then we simply don't care that the
backend isn't working. That is, if nobody cares to maintain the
backend, then it just isn't important enough to maintain.
4. The maintainers have complete control over their backend. They
don't need design decisions if a change concerns only their backend.
Of course, if they do really stupid decisions then we will find a new
maintainer.
If Shai's recent contributions are an indication of how such a system
might work, then the system is going to work very well...
- Anssi
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
