Further Reading: Testing and Debugging

pytest Documentation and Tutorials

pytest official documentation — docs.pytest.org (Tier 1) The definitive reference for pytest. Includes tutorials, how-to guides for fixtures, parametrize, markers, plugins, and advanced configuration. Start with "Get Started" if you want a walkthrough; jump to "How-to guides" when you need something specific.
Okken, B. (2022). Python Testing with pytest, 2nd Edition. Pragmatic Bookshelf. (Tier 1) The best dedicated book on pytest. Covers everything from basic tests through fixtures, parametrize, plugins, and CI integration. Written for developers who already know Python basics — which is exactly where you are now.

Beck, K. (2003). Test-Driven Development: By Example. Addison-Wesley. (Tier 1) The original TDD book by the person who popularized the technique. Uses Java and Python examples. The first part walks through a complete TDD project step by step — it's a masterclass in the Red-Green-Refactor rhythm. Still the best introduction to the TDD mindset decades after publication.
Percival, H. (2025). Test-Driven Development with Python: Obey the Testing Goat, 3rd Edition. O'Reilly. (2nd edition 2017.) Free to read online at obeythetestinggoat.com. (Tier 1) A full-length TDD tutorial using Python and Django (a web framework). Goes well beyond this chapter into web testing, but the first few chapters are excellent for understanding TDD with Python specifically. The online version is free under a Creative Commons license.

Zeller, A. (2009). Why Programs Fail: A Guide to Systematic Debugging, 2nd Edition. Morgan Kaufmann. (Tier 1) An academic but accessible treatment of debugging as a systematic discipline. Covers scientific debugging, delta debugging, and automated fault localization. More advanced than what we covered in this chapter, but invaluable if you want to go deeper.
Agans, D. (2002). Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems. AMACOM. (Tier 1) A short, practical, and entertaining book on debugging strategies. Not Python-specific — the rules apply to any kind of troubleshooting. Rule 4, "Divide and Conquer," is the binary search debugging strategy from Section 13.8, and Rule 3, "Quit Thinking and Look," is a good argument for print statements and debuggers over guesswork.

Winters, T., Manshreck, T., & Wright, H. (2020). Software Engineering at Google: Lessons Learned from Programming Over Time. O'Reilly. (Tier 1) Chapters 11-14 ("Testing Overview," "Unit Testing," "Test Doubles," and "Larger Testing") cover Google's approach to testing at massive scale. Chapter 11 is particularly relevant — it discusses the testing pyramid, test size classification, and when tests provide value. Google provides a free HTML version at abseil.io/resources/swe-book.
Fowler, M. (2012). "TestPyramid." martinfowler.com/bliki/TestPyramid.html (Tier 2) A concise article explaining the testing pyramid (many unit tests, fewer integration tests, few E2E tests) and why this distribution works. Good companion to Section 13.2.

pytest-cov documentation — pytest-cov.readthedocs.io (Tier 1) Documentation for the pytest coverage plugin. Shows how to generate HTML coverage reports, configure coverage thresholds, and integrate coverage into CI pipelines.
Fowler, M. (2012). "TestCoverage." martinfowler.com/bliki/TestCoverage.html (Tier 2) A short, influential article arguing that coverage is a useful diagnostic tool but a terrible goal. Fowler expects well-tested code to land in the upper 80s or 90s and treats 100% with suspicion, which is where Section 13.10's guideline comes from.

Hypothesis library — hypothesis.readthedocs.io (Tier 1) A property-based testing library for Python. Instead of writing specific test cases, you describe properties that should hold for any input, and Hypothesis automatically generates hundreds of random test cases. A fascinating next step after you've mastered traditional unit testing.
mutation testing (mutmut) — Search for "mutmut Python mutation testing" (Tier 2) Mutation testing works by introducing small changes (mutations) into your code and checking whether your tests catch them. If a mutation doesn't cause any test to fail, your tests have a gap. It's a way to test your tests.