Carl Meyer’s Testing Talk At PyCon 2012

In this age and time, any decent web developer takes testing seriously. However testing a piece of code correctly1 and efficiently2 is not as simple as it seems to developers with less experience.

Here are my take-aways:

• The distinction between slow tests and fast tests is important. Slow tests are integration/functional/regression/system tests and fast tests are unittests. Ideally you should write a lot of unittests that tests small bits of code in isolation. Slow tests should be used sparingly for testing the most important interactions between the components. You can have a unittest suite that runs very quickly and another test suite that contains all the tests but not necessarily run every single time.
• Fixtures are considered harmful. For quick and dirty setups, if you need just a few objects fixture are OK. But for serious testing generating models on the fly has advantages. Most importantly it makes it easier to completely decouple test setups. It is not practical to create fixtures for every single test method after all. I am recently having trouble maintaining fixtures after schema changes. @carljm mentions factory_boy, I’ll give it a spin.
• There is a nice tip about mock.patch()’ing the CursorWrapper to raise an exception when instantialized.
• Keep you views thin. Django has all the tools to make this easy. If you view is, say, longer than 10 lines of code; think how you can split the functionality into other components. Can you mode some of the code into a model method or make it a template tag/filter? Also having a class based view doesn’t necessarily mean it has to do everything itself.
• Test client considered harmful. I have been avoiding using the test client except when I really have to. It know too much about the internals of Django, therefore it gives less confidence than, say, a Selenium test. I didn’t know about WebTest before. It talks WSGI with your code, therefore it’s sufficiently ignorant about the internals.
• Multi-step tests are for n00bs. Write many focused tests instead of stringing assertions back to back. It will make maintenance and debugging easier.

1: Correctly, so that your tests give you enough confidence in your code.

2: Efficiently, so that you keep running them and you keep writing them.