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?
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/54FB6A26.5050906%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
