Initial data, tests and migrations
Tom Evans
I'm having some difficulty working out how I am supposed to provide
initial data for testing purposes, particularly when the initial data
is not immediately pertinent to the test.
For instance, our project uses django_otp, which has some simple
tests. However, these tests create user objects, which then calls in
to other parts of the project code. This code adds users to various
auth.Group, depending upon the user attributes. This code fails after
the first test has been run, because all the auth.Group model
instances are flushed from the database.
Previously, these instances were loaded from a JSON fixtures file,
which used to be the recommended way. For our own tests, we simply
load these fixtures in the setUp portion of the test; obviously we
can't go around modifying tests in third party libraries.
I tried taking them out of the fixtures, and adding them instead in a
data migration, but this also had the same effect - the instances were
there for the first test ran, and then missing for all the subsequent
ones.
What is the "correct" way of ensuring that these instances exist in
the test database before any test is run?
How can I stop them getting wiped out after any test has run?
Cheers
Tom
Melvyn Sopacua
On Tuesday 21 February 2017 19:00:42 'Tom Evans' via Django users wrote:
> Previously, these instances were loaded from a JSON fixtures file,
And you can still do that.
> which used to be the recommended way. For our own tests, we simply
> load these fixtures in the setUp portion of the test; obviously we
> can't go around modifying tests in third party libraries.
> I tried taking them out of the fixtures, and adding them instead in a
> data migration, but this also had the same effect - the instances were
> there for the first test ran, and then missing for all the subsequent
> ones.
setUp is run between test methods of a test case. setupTestData is a class method on the testcase run once per test case.
>
>
> What is the "correct" way of ensuring that these instances exist in
> the test database before any test is run?
All explained in the docs.
Either redeclare the same fixtures for different test cases or reorganize your testcases to share the same fixture(s).
--
Melvyn Sopacua
Tom Evans
1) The test cases belong to a library and cannot be modified
2) The initial data is populated from a data migration and not from a
fixture, as that is not recommended [1]
Data is placed in to the test database using migrations, but after the
first test has been run the data is flushed out again, causing the
second test to fail.
I would like the all the tests to pass:
* I don't want to put the same data into fixtures as well as migrations (DRY)
* I don't want to modify the 3rd party library.
How?
Cheers
Tom
[1] https://docs.djangoproject.com/en/1.10/howto/initial-data/#providing-initial-data-with-migrations
Tim Graham
* https://groups.google.com/d/topic/django-developers/nj_Zha341pA/discussion
Adam Stein
-- Adam (ad...@csh.rit.edu)
Tom Evans
Cheers
Tom
Tom Evans
> I'm curious if you feel that running django_otp's tests as part of your
> project's tests is adding value.
that I don't think add value...
django_otp is simply an example of this issue, but yes, running those
tests would give my project value.
These tests exercise parts of django_otp that interact with parts of
my code. Successful tests indicate that those two parts interoperate
correctly. The tests are successful when run individually, but fail
when run as a suite because data loaded as part of a migration is
flushed away before the second test.
Melvyn Sopacua
On Wednesday 22 February 2017 14:22:36 'Tom Evans' via Django users wrote:
> On Wed, Feb 22, 2017 at 12:47 AM, Melvyn Sopacua <m.r.s...@gmail.com> wrote:
> > On Tuesday 21 February 2017 19:00:42 'Tom Evans' via Django users wrote:
> >> What is the "correct" way of ensuring that these instances exist in
> >>
> >> the test database before any test is run?
> >
> > All explained in the docs.
> >
> > Either redeclare the same fixtures for different test cases or
> > reorganize your testcases to share the same fixture(s).
>
> I think you have misunderstood:
>
> 1) The test cases belong to a library and cannot be modified
So don't use them as is or prompt the authors to update to the new way of things. In transition, you can extend the test cases and simply add a fixture attribute.
> 2) The initial data is populated from a data migration and not from a
> fixture, as that is not recommended [1]
Data migrations for the project are never relevant for tests, since the test database is empty. You're putting a label on "fixtures" that is only relevant for the provided context. Fixtures are not deprecated, not bad for you and do not mess up your aura.
On one hand It is as Adam says:
" It would seem to me that the docs are telling you to use fixtures for tests and use migrations for real data."
Adding to that - fixtures are still a solid way to load application data - only the use of "initial" or "autloaded" data is discouraged.
Fixtures should be used on production databases to selectively provide data, so that the user of the application can load "google_shopping.json" if it wants to publish it's products Google Shopping or not load it, if she doesn't.
--
Melvyn Sopacua
Adam Stein
Cheers Tom
-- Adam (ad...@csh.rit.edu)
Melvyn Sopacua
On Wednesday 22 February 2017 15:13:47 'Tom Evans' via Django users wrote:
> These tests exercise parts of django_otp that interact with parts of
> my code. Successful tests indicate that those two parts interoperate
> correctly. The tests are successful when run individually, but fail
> when run as a suite because data loaded as part of a migration is
> flushed away before the second test.
So they're different tests: they make use of the logic of the library's test suite, but operate on your data. Schoolbook example for inheritance:
from django_otp.tests import SuperTest
class SuperTestWithMyData(SuperTest):
fixtures = ['my_data']
--
Melvyn Sopacua