#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 [email protected].
To post to this group, send email to [email protected].
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.
