On May 8, 12:50 am, Anssi Kääriäinen <[email protected]> wrote:
> On May 5, 4:31 pm, Andreas Pelme <[email protected]> wrote:
>
>
>
>
>
>
>
>
>
> > > On May 4, 2:30 pm, Karen Tracey <[email protected] (http://gmail.com)>
> > > wrote:
> > > Thanks for the link. While reading the previous threads I spotted at
> > > one blocker issue: the first TransactionTestCase will not start with
> > > zeroed database sequence values. To prevent this one would need to
> > > flush the DB before the first TransactionTestCase. In addition, if the
> > > goal is to get rid of test ordering, then one would need to flush
> > > before every test case which isn't good. Getting rid of the
> > > requirement to reset sequences between test cases would be good.
> > > Oracle doesn't reset the sequences reliably currently just for
> > > example. But I don't think we can change that for backwards
> > > compatibility reasons. While tests that rely on sequence values are
> > > IMHO broken, changing this would result in numerous broken tests for
> > > users upgrading Django. Notably normal TestCases do not do sequence
> > > resetting at all currently.
>
> > > This is a blocker: why change the flushing from pre-test to post-test
> > > if the end result is that you can't run the tests in arbitrary order
> > > anyways? Or if you want to be able to run them in arbitrary order you
> > > will need to run at least the sequence resets pre-test anyways.
> > > Resetting sequences can be really expensive, so there goes any
> > > potential savings in speed.
>
> > > Ideas?
>
> > Agreed, it is indeed backward incompatible. However, I think we can make
> > the upgrade for those affected very anyways:
>
> > * Document this change properly in the release notes and in the testing
> > docs
> > * Document that tests should not depend on hard coded primary key values
> > (this is already hinted in the testing docs where
> > TestCase/TransactionTestCase is described)
> > * Add a reset_sequences attribute on TransactionTestCase, that can be
> > applied to existing TransactionTestCase tests that already uses hard coded
> > primary key value - which will reset sequences *before* the test run, just
> > like before. (And those tests will also flush the database after they are
> > run)
>
> > I have updated the pull request with the reset_sequences attribute and an
> > initial draft for the release notes and
> > documentation:https://github.com/django/django/pull/45
>
> > 1.1 introduced a far greater change to testing behavior (the TestCase with
> > transaction/rollback), if that change was considered acceptable from a
> > backward compatibility perspective, this change should be too. When that
> > happened, the same problem appeared since TestCase does not reset
> > sequences. (Yeah, just because it was done in the past does not make it OK
> > now, but that should give some perspective).
>
> > I guess it boils down to where to draw the line for backward compatibility
> > here. :-) I personally think it is acceptable since we can offer a very
> > easy fix for the existing (already broken) tests out there.
>
> I would like to just get rid of the sequence resets. Oracle doesn't do
> it currently, TestCase doesn't do it, and IMO assuming the IDs are
> going to start from 1 is an assumption one should not make.
>
> Objections to just getting rid of the sequence resets altogether (with
> the opt-in flag)?
>
> - Anssi
Just another idea: Maybe the right approach is to add flags to
TransactionTestCase (reset_sequences, track_state, track_fixtures,
more_ponies,...) and then recommend use of own subclasses in testing.
Something like:
class MyTestCase(TransactionTestCase):
reset_sequences = False
track_state = True # (flush only dirty tables).
track_fixtures = True # (Track if fixture data needs reloading
between tests).
class LoginLogouTests(MyTestCase):
fixtures = ['auth-user.json']
def test_login(self):
...
The defaults should be conservative (safe but slow). If there are
mysterious test case failures it will be easy to just comment out all
the flags to check if the test failures are explained by dirty state.
Similarly you could have "MySeleniumTestCase" subclass for selenium
tests.
This also allows deprecation of reset_sequences (or changing the
default from True to False) if we want to do so in the future.
It seems hard to provide subclasses in Django core, as that will lead
to combinatorial explosion down the road. Maybe mixins is the right
approach. I haven't used mixins based approaches, so I don't know how
easy it is to do the above using mixins.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
