Which tests are worth writing and which aren't? Chasing complete coverage is a waste of effort, and leads you to write bad tests. I'll describe two kinds of bad tests and show examples, and I'll share my principles for designing good tests. By choosing where to focus your efforts, and importantly where not to test, you can achieve a high degree of confidence in the correctness of your code without sacrificing speed, or risking unreliable tests. Next we will examine in detail the question of test assertions. The best tests assert about every possible output from a function or class under test, right? Of course it's important to thoroughly test your code. I will demonstrate how to structure tests so that failures point you immediately in the direction of the issues in your codebase, and how to use good object-oriented principles to make your tests serve as both readable and executable documentation of your code's behavior. Finally, we will examine the thorniest of testing scenarios, the infamous integration test. Many Python programmers favor the Mock library, which, if used carefully, is indeed a powerful tool. It should be considered an advanced weapon in your testing toolkit, to be used only sparingly and with great care, for mocking carries with it great risks: you might end up testing nothing! I'll show how to avoid the risks of overly-magic testing, and where parts of the Mock library are safe.