On Sunday, March 8, 2015 at 12:16:43 AM UTC+3, Some Developer wrote: > > On 06/03/15 16:23, Ilya Kazakevich wrote: > > You may start from highest level testing: > > 1) create "usage scenarios" for your website. Like "customer opens page > > 'foo', and should see 'bar'". You use such scenarios for manual testing, > > right? > > 2) code such scenarios against Django project. You may use BDD testing > > tools (like lettuce or behave), or do it in pure python. You may call > > Django views and templates directly (using django unittesting support or > > lettuce/harvest), or do it through the browser using Selenium. One > > scenario -- one method. Yes, there is a lot of boilerplate code, but you > > only need to write it once. BDD tools are used to simplify this process > > by writing scenarios on DSL called Gherkin, which is easier. > > > > This is some kind of "acceptance testing", the one that helps you to be > > sure website works like customer expects it to work. Every project > > should have one, I believe. > > > > After it, you may find that some units of your system are complex and > > error prone. What is unit? Unit is module, function or even package with > > _clear interface_. You then create unit tests against this module. Only > > units with complex logic need to be tested. No need to test simple view > > that just returns render(): this view is tested as part of high level > > testing. But if you have function "calc_user_amount" and complex > > business logic stands behind it, you may create unit test for it. > > > > There are 3 mistakes people do about testing: > > 1) Testing each function, even private function, even 1 line function. > > It takes a lot of time, and such tests are fragile. You throw'em away > > after simple refactoring. > > 2) Testing "in the middle of abstraction": I mean testing functions with > > out of clear interface, like private functions. If you need to read > > function code before writing test (pydoc is not enough), you should not > > test this function. Try a higher level of abstraction. > > 3) Skipping high level testing: even if all your code is covered with > > low-level unit-tests, you still need high level testing like the one > > with Selenium to make sure everything works correctly, and when you > > refactor your code you use such testing to make sure you did not break > > anything. > > > > So, you start with high level, and then cover _some_ units with unit > > test, if you believe they may contain error. > > > > Awesome advice. Thanks! > > I bought a book called "Test Driven Development using Python" and have > had a look through it a bit. It does seem a bit over the top (write no > code until you have a unit test for it in existence even if it is just a > one liner view function) but hopefully I'll be able to take some of the > advice and use it to fix up my code base. > > Has anyone else read the book? Any opinions? >
I have read the book and it got me started in Django when I knew absolutely nothing about testing. Though it might be a bit over the top, it manages to teach you the concepts so that you can later on apply on them on your own. I highly recommend it. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/24e0e29c-5e3d-4750-aebe-96d49fac247f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
