Description
Units Need Testing Too
Presented by Gary Bernhardt
Python's long history of testing has focused primarily on integration- and system-level tests: slow-running tests executing lots of code. These are a great start, but many of them can be transformed into unit-level tests. True unit tests are orders of magnitude faster (about 1ms each), providing quicker feedback and better failure localization. We'll look at why and how to write them.
Abstract
Python has a wonderful legacy in testing: PyUnit has been in the standard library since March, 2001, and it was already a year old by then. We adopted browser driving quickly, and we do it at huge scale with great test parallelization infrastructure.
Big tests aren't everything, though. In the Python world, true unit tests are somewhat rare, and even most tests written with the unittest library are integration tests. These tests are slow to execute and don't localize failure as well as smaller, focused tests. They leave us with two options: either run them rarely, sacrificing feedback, or run them often, sacrificing speed.
Writing true unit tests removes that particular trade-off. When your tests execute in a millisecond each, you can afford to run a thousand of them every time you save a source file. This talk will discuss what unit tests really are, why they matter, and how to write them in Python.