#28983: Documentation on providing initial data with migrations is unhelpful
-------------------------------------+-------------------------------------
Reporter: Rob Atkinson | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Documentation | Version: 2.0
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Rob Atkinson):
Happy to suggest some documentation clarifications once I have got my test
cases working..
I have been using setUp() for the data, but there is some initial data i
want autoloaded in all environments, and as this is part of the app i
want to do unit tests on the loading process too. i got a bit lost in the
deprecation discussion around fixtures - is this auto loading something we
want to do in migrations?
Then i want to add some additional data, currently using setUp() - but
setUpTestCase() should be fine - but here the question is the inheritance
one - if i am testing an app that extends this app - the perhaps the
pattern is to import and extend the test case and inherit these methods
too? If the extended add needs to add data - does it override
setUpTestCase() and then call super.setUpTestCase()?
Finally (and this is my ultimate use case) - i have an app that allows a
user to load a file and process it using metadata they provide. This app
is then extended for specialised resource types - so i want a test case
for a FileField.
IMHO the testing guidelines should cover (at least with links to more
information) the following common patterns
- separation of unit and integration tests (is testing parsing of an
uploaded file in an app a unit test? - i can test the parser separately -
but i want to unit test the selection and setup of the parser with the
uploaded file and other user supplied metadata )
- testing FileField CRUD operations (as these seem to require user code
to handle cleanups then testing is vital -
https://docs.djangoproject.com/en/2.0/topics/files/ does not provide
information on how deletions are managed or testing processes - but if its
handled automatically and we dont need to test this ourselves then lets
add a note to explain that)
- testing views that use external services. (there are various references
to mocking and third party tools, but this seems to be a key function and
the docs are silent) - for example, we wouldnt have a government
application locally that wouldnt use the mandated official external street
address validation service
--
Ticket URL: <https://code.djangoproject.com/ticket/28983#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.999b7fb4892894272db9ea0810378d91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
