What's the different between regressiontests/signals_regress and modeltests/signals?

12 views
Skip to first unread message

Silver_Ghost

unread,
Sep 29, 2011, 3:04:22 AM9/29/11
to django-d...@googlegroups.com
`regressiontests/signals_regerss` was created in changeset 11710 and `modeltests/signals` was created in changeset 6269.  It seems that they perform same tests.  And where should I place tests for ticket 4528?

Russell Keith-Magee

unread,
Sep 29, 2011, 9:08:15 AM9/29/11
to django-d...@googlegroups.com
On Thu, Sep 29, 2011 at 3:04 PM, Silver_Ghost <silver...@gmail.com> wrote:
> `regressiontests/signals_regerss` was created in changeset 11710 and
> `modeltests/signals` was created in changeset 6269.  It seems that they
> perform same tests.

The distinction between modeltests and regressiontests is a historical
artefact; once upon a time, Django used the "modeltests" directory as
part of our documentation -- they were intended as samples of code
that explained the various APIs by example.

We stopped doing this some time ago, but the split still exists --
mostly because merging test suites is a PITA to do :-)

If you *really* want to find an after-the-fact explanation, I suppose
you could say the modeltests are tests of basic functionality, and the
regressiontests are tests of obscure edge cases; but even that
distinction is a little vague, and not completely adhered to.

Based on the history of the two directories, I'm going to guess that
the overlap in tested functionality is mostly accidental; r11710 was a
big refactor of the way m2m signals worked, and I'm guessing I just
added a bunch of tests to make sure a specific piece of functionality
was tested fully. I'd have to go digging to give you more detail than
that.

As for where to put tests for #4528; that's a bit harder. syncdb
behavior is notoriously difficult to test, because the test system
needs to run syncdb in order to run the test suite. We often resort to
implied testing when it comes to syncdb; i.e., we rely on the fact
that the test suite doesn't run if syncdb is broken, so if the test
suite runs, syncdb must be working. This isn't an ideal situation, but
it's a pragmatic solution.

That said -- if something *can* be tested, it should be, so you're
encouraged to get creative. If you do work out a way to test this
feature, a completely new test directory is probably called for
(regressiontests/syncdb would seem like a good place to me).

Yours
Russ Magee %-),

Reply all
Reply to author
Forward
0 new messages