Thanks Melvyn Yes, over time I have come to learn the need for fat models and Useful Managers, plus having logic not embedded in the views (especially for processing of data arising from a form). So views are mostly "handlers" to ensure that the forms are presented, the data is retrieved and passed on to a processing method, and then the flow redirected to the right URL.
I have got hung up on the "mechanics" of form testing instead of seeing that they only play a small role in the project. I will however, persist until I get the grammar correct. Derek On 3 September 2017 at 16:14, Melvyn Sopacua <m.r.sopa...@gmail.com> wrote: > It certainly isn't trivial. > > First and foremost, write fat models and Managers, but lean views. > > Rather then putting complex queries in views, I have a strong bias > to writing manager methods (or QuerySet methods, if I feel it's > reusable in more then one Manager - see Manager.from_queryset [1]). > > Further more, I tend to use the setup described here [2] also for > projects. But for the `test_settings.py` I use: > > from project_app.settings import * > > INSTALLED_APPS += ['tests.apps.TestsConfig'] > > This makes it trivial to test fields on their own, by creating models > that only exist in the test environment. > > Normally, you want to test all components on their own, but with > forms being so tightly coupled to and influenced by views and urls, > it is non-trivial to predict what affects your form and thus test for it. > It's easy to get 100% coverage on your form and still know nothing, > because the input variations are important. > Yes, it's possible to do with different initialization, but you're going > to test your views anyway, so why not use the test client, as your > views eventually determine what happens with them and are pretty > much the only way to use them. On top of that, you're testing your > urls for free. > > So in general, a Django test suite consists of: > * model tests > * view tests using django.test.Client > * template tests [3] > * command tests [4] > * utility tests > > Hope this helps, > > [1] https://docs.djangoproject.com/en/1.11/topics/db/ > managers/#creating-a-manager-with-queryset-methods > [2] https://docs.djangoproject.com/en/1.11/topics/testing/ > advanced/#testing-reusable-applications > [3] shameless plug warning: > http://django-xtc.readthedocs.io/en/latest/index.html > [4] https://docs.djangoproject.com/en/1.11/ref/django-admin/# > django.core.management.call_command > > On Sun, Sep 3, 2017 at 10:05 AM, Derek <gamesb...@gmail.com> wrote: > > I have been looking for a decent guide that covers testing in a solid, > > thorough way - there are lots of fragmented pieces that cover > > bits-and-pieces of what is needed for tests but not all the cases with a > > start-to-end comprehensive approach for everything ("Obey the Testing > Goat" > > comes closest). I need to cover cases for the admin as well - with > actions > > and intermediate forms, some with file uploads. In those case, I assume > (?) > > that the action logic is equivalent to a view. > > > > The Django docs show examples as well but I have not see where they cover > > everything. > > > > This may all seem like trivial knowledge to people who have already done > all > > this, but I struggle to see the full picture of what a whole test suite > > should look like, and what the details of all the tests would be. > > > > > > On 3 September 2017 at 09:07, James Schneider <jrschneide...@gmail.com> > > wrote: > >> > >> > >> > >> On Sep 1, 2017 3:00 PM, "Derek" <gamesb...@gmail.com> wrote: > >> > >> Thanks Melvyn > >> > >> I already have tests for the processing of data when it has been > uploaded > >> - which is actually the critical issue for the application. The "view" > is > >> just really a thin wrapper around the two steps : form display & upload > and > >> then the file processing itself : and those are the parts I need tests > for. > >> > >> > >> I'd have to agree with Melvin. You should be testing your view code as > >> well, which would incorporate the tests for the form class. If the view > is > >> broken out interacts badly with the form for whatever reason, the fact > that > >> the form works on it's own is irrelevant. Plus it isn't that hard to > add in. > >> > >> I would test the view even if it is boiler plate code shared by all of > >> your forms, because you need to be certain that the combination of the > view > >> and form in question work together. > >> > >> -James > >> > >> -- > >> You received this message because you are subscribed to a topic in the > >> Google Groups "Django users" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/django-users/GUStj-3rzD8/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > >> django-users+unsubscr...@googlegroups.com. > >> To post to this group, send email to django-users@googlegroups.com. > >> Visit this group at https://groups.google.com/group/django-users. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/django-users/CA%2Be% > 2BciUgbWkGFVrqBWKAYdifP%2BjTchZwHR0-GfPKGcTjP%3DBjfA%40mail.gmail.com. > >> > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to django-users+unsubscr...@googlegroups.com. > > To post to this group, send email to django-users@googlegroups.com. > > Visit this group at https://groups.google.com/group/django-users. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/django-users/ > CAF1Wu3MqT1V85StnBg8D_eqrcjH%2BebjvDW41xg_V1t%3D9%3DeUk-Q%40mail.gmail.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Melvyn Sopacua > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/django-users/GUStj-3rzD8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/CA%2Bgw1GWjFqepbgnGQsGRH1HyJ18vi3 > x39gfYB%2Bkkk30Vg5L9eg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAF1Wu3MeMrXxcqynpWfXQ_wp7WVm%2Bo97yP53y2nyUUAsqrTuZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
