Improving test data experience
Jeremy Dunck
I've got a codebase with a fair bit of fixtures and have been
experiencing some pain around it. One of the pains is migrating the
format of fixtures when a schema change occurs.
I posted a thread to south-users to discuss the idea of adding a
feature to aid applying migrations to fixture data:
http://groups.google.com/group/south-users/browse_thread/thread/e358d13a55545082
Evgeny responded that perhaps scripting generation of the fixture
was a good approach, and Carl responded that he thinks that generating
the needed test data in the TestCase itself is preferable. Both
approaches avoid the immediate problem of wishing I could migrate
fixture data, because generating the data under their approaches
avoids having fixtures as an authoritative source of data.
That surprised me a bit since I generally have viewed fixtures as
things to set up once. Have others on the list tried these approaches
(or other approaches) and have any thoughts you'd like to share on it?
In any case, I think it would be good to do one or both of the following:
1) expand on the testing guide to present fixtures as one option
for test data and point out the options to script fixture generation
or avoiding fixtures in favor of TestCase-called generation,
discussing tradeoffs in the approaches
2) add a django-admin testshell command which would act like
testserver - loading fixtures into a test DB and dropping you into the
shell to munge it as needed; this would be paired with a south feature
for applying migration fixtures.
Feedback, please?
Alex Gaynor
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
I basically agree with what Carl said, but if you want to use fixture files, I highly reccomend: https://github.com/alex/django-fixture-generator
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
Adrian Holovaty
> 1) expand on the testing guide to present fixtures as one option
> for test data and point out the options to script fixture generation
> or avoiding fixtures in favor of TestCase-called generation,
> discussing tradeoffs in the approaches
I would support this. Seems like good documentation to have.
> 2) add a django-admin testshell command which would act like
> testserver - loading fixtures into a test DB and dropping you into the
> shell to munge it as needed; this would be paired with a south feature
> for applying migration fixtures.
Just to be clear, how would you get the "diff" of what's changed?
Would it automatically change the fixture files after you close the
shell session? Or would that be up to you?
Adrian
Ned Batchelder
FWIW, this is the process I've used in the past:
http://stackoverflow.com/questions/4002322/migrating-django-fixtures
There's got to be a better way.
--Ned.
h3
this existed:
https://gist.github.com/1414209
On Nov 30, 10:36 pm, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 11/30/2011 5:22 PM, Jeremy Dunck wrote:
>
>
>
>
>
>
>
> > Hi all,
> > I've got a codebase with a fair bit of fixtures and have been
> > experiencing some pain around it. One of the pains is migrating the
> > format of fixtures when a schema change occurs.
>
> > I posted a thread to south-users to discuss the idea of adding a
> > feature to aid applying migrations to fixture data:
> > http://groups.google.com/group/south-users/browse_thread/thread/e358d...
Aymeric Augustin
> On Wed, Nov 30, 2011 at 4:22 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
>> 1) expand on the testing guide to present fixtures as one option
>> for test data and point out the options to script fixture generation
>> or avoiding fixtures in favor of TestCase-called generation,
>> discussing tradeoffs in the approaches
>
> I would support this. Seems like good documentation to have.
I agree that we should suggest alternatives to fixtures, and I think we should emphasize object generation rather than fixture scripting.
Object generation is vastly simplified with factories, since they take care of creating automatically dependent instances (non-nullable foreign keys). Factories are also easier to keep in sync with model changes than fixtures.
In my current job we're using https://github.com/rbarrois/factory_boy, we've dropped all but the most trivial fixtures (sites, languages, an admin user), and we haven't looked back.
Best regards,
--
Aymeric Augustin
Jeremy Dunck
<aymeric....@polytechnique.org> wrote:
...
> In my current job we're using https://github.com/rbarrois/factory_boy, we've dropped all but the most trivial fixtures (sites, languages, an admin user), and we haven't looked back.
Nifty, thanks.
Jeremy Dunck
....
> Just to be clear, how would you get the "diff" of what's changed?
> Would it automatically change the fixture files after you close the
> shell session? Or would that be up to you?
Yes, I was thinking of catching SystemExit, KeyboardInterrupt or maybe
using atexit and dumping at that time.
We're all using source control here, right? :-)
I guess another thing we could do is provide a function that could be
called to finalize the fixtures.
./manage.py testshell
>>> # hackety hack
>>> from django.... import finalize_fixtures
>>> finalize_fixtures()
^C