of work (or code) • Unit tests should be small and thus fast (100s of tests in a couple seconds fast) • Unit tests should ignore collaborators • Unit tests should test one bit of behavior • Units of code should be well factored and will make unit testing easier
example: • If class A uses an instance of class B, class B is the collaborator • If class A talks to example.com, example.com is the collaborator • If a unit of code opens a file, that file is the collaborator • Disclaimer: We will not discuss integration testing here
parametrization. Yes, it trips me up very often • This allows you to have many different inputs to a test function so you can write fewer lines of code but have more tests. If you have a test function with N items parametrizing it, you will have N tests appear in your test run. 1 for each set of parameters.
and branches in your code are exercised by your tests • Many projects aim for 100% test coverage • Test coverage is a lie but still very useful to have
Refers to the practice of writing a test before writing the code that the test exercises • If you are adding a new method to a class, you write the test for that method first, then write the method and run the tests to see if the method satisfies the test you wrote
updated • Beautiful test output + tonnes of plugins • Does not require classes (tests can be plain functions) • Uses assert statement, supports parametrization, has test fixtures • Works perfectly with unittest
library • python -m pip install pytest • Has some very sharp very narrow and very bizarre corner cases (not going to go into these now or in questions)
updated • Helps excise pesky collaborators • So valuable it was added to the standard library in Python 3.4 • Actually lives as unittest.mock in Python 3.4+ • Can patch out objects, functions, etc. • Works with unittest, pytest, whatever