On 03/06/2015 11:23 AM, 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.
This is really excellent advice. Carl -- 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/54F9FA6E.8050001%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
