Testing in Python Cheat Sheet

Updated 2026-04-27

Next Topic: Trees and Binary Search Trees Cheat Sheet

🧠Study flashcards on this topic105 cards · spaced repetition→

Testing in Python encompasses a rich ecosystem of frameworks, tools, and methodologies for verifying code correctness through unit tests, integration tests, and functional tests. The landscape is dominated by pytest (the modern standard with powerful fixtures and plugins) and unittest (the built-in framework following xUnit patterns), though both share the fundamental goal of catching bugs before production. The key insight: testing isn't just about running assertions—it's about structuring tests for maintainability, isolation, and speed, using fixtures to manage setup/teardown, mocks to control dependencies, and parametrization to test multiple scenarios without code duplication.

What This Cheat Sheet Covers

This topic spans 17 focused tables and 131 indexed concepts, 105 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Test Types and StrategiesTable 2: Testing FrameworksTable 3: Test Discovery and ExecutionTable 4: AssertionsTable 5: Fixtures (pytest)Table 6: Setup and Teardown (unittest)Table 7: ParametrizationTable 8: Mocking and PatchingTable 9: Test Markers (pytest)Table 10: Test CoverageTable 11: Test Organization PatternsTable 12: Async TestingTable 13: Special Fixtures (pytest)Table 14: Property-Based TestingTable 15: Pytest PluginsTable 16: CI/CD and AutomationTable 17: Advanced Techniques

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Test Types and Strategies

Not all tests are equal, and choosing the right kind is the first design decision in any test suite. These range from tiny, fast unit checks up to slow end-to-end flows, with the test pyramid offering the rule of thumb for how many of each to write—many at the bottom, few at the top.

Type	Example	Description
Unit test	`def test_add():` `assert add(2, 3) == 5`	• Tests a single function or class in complete isolation • fastest and most numerous tests in a well-structured suite.
Integration test	`def test_user_repo():` `repo = UserRepo(db)` `assert repo.find(1) is not None`	• Tests multiple components working together • slower than unit tests but catches interaction bugs between layers.
End-to-end test	`page.goto("/login")` `page.fill("#user", "admin")` `page.click("button[type=submit]")`	• Tests the full user workflow through the UI • slowest and fewest, typically powered by Playwright or Selenium.
TDD (red-green-refactor)	`# 1. write failing test (red)` `# 2. minimal code to pass (green)` `# 3. improve code (refactor)`	• Write a failing test first, make it pass with minimal code, then refactor • drives design through tests.
BDD (behavior-driven)	`Given I have valid credentials` `When I log in` `Then I see the dashboard`	• Tests written as human-readable Gherkin scenarios • bridges developers and non-technical stakeholders.
Test pyramid	`~70% unit / ~20% integration / ~10% e2e`	Guideline for test ratio: many fast unit tests at the base, fewer slow e2e tests at the top.
Smoke test	`@pytest.mark.smoke` `def test_app_starts():`	• Fast sanity check that critical paths work after a deployment • run as a subset of the full suite.
Regression test	`def test_bug_1234():` `assert fixed_behavior()`	• Verifies a previously fixed bug has not reappeared • every bug fix should have a corresponding test.

Table 2: Testing Frameworks

Python's testing world centers on pytest and the built-in unittest, but the ecosystem is broader than those two. The frameworks here span styles—plain-assert pytest, xUnit-style unittest, docstring-embedded doctest, and Gherkin-based BDD tools—so the choice usually comes down to your team's conventions and who needs to read the tests.

Framework	Example	Description
pytest	`def test_addition():` `assert add(2, 3) == 5`	• Modern framework using plain `assert` • automatic test discovery, powerful fixtures, extensive plugin ecosystem — the current industry standard.

The rest of this section is part of the full cheat sheet

Table 3: Test Discovery and Execution

Pytest and unittest find your tests automatically, but only if you follow their naming conventions—get the test_ prefixes wrong and your tests silently never run. These patterns cover how files and functions are discovered, how to filter and preview what will run, and why isolation between tests is what makes parallel execution safe.

Pattern	Example	Description
test file naming	`test_.py` or `_test.py`	Files must start with `test_` or end with `_test.py` for automatic discovery by pytest and unittest.

The rest of this section is part of the full cheat sheet

Table 4: Assertions

Assertions are where a test actually decides pass or fail, and Python gives you two distinct dialects. Pytest leans on the plain assert statement with rich failure introspection, while unittest offers a family of explicit assertEqual/assertRaises-style methods—the float-tolerant and exception-catching variants here are the ones worth memorizing.

Method	Example	Description
assert statement	`assert result == expected`	Pytest uses plain Python `assert` with automatic introspection — shows intermediate values on failure without any extra code.

The rest of this section is part of the full cheat sheet

Table 1: Test Types and Strategies

Type	Example	Description
Unit test	`def test_add():` `assert add(2, 3) == 5`	• Tests a single function or class in complete isolation • fastest and most numerous tests in a well-structured suite.
Integration test	`def test_user_repo():` `repo = UserRepo(db)` `assert repo.find(1) is not None`	• Tests multiple components working together • slower than unit tests but catches interaction bugs between layers.
End-to-end test	`page.goto("/login")` `page.fill("#user", "admin")` `page.click("button[type=submit]")`	• Tests the full user workflow through the UI • slowest and fewest, typically powered by Playwright or Selenium.
TDD (red-green-refactor)	`# 1. write failing test (red)` `# 2. minimal code to pass (green)` `# 3. improve code (refactor)`	• Write a failing test first, make it pass with minimal code, then refactor • drives design through tests.
BDD (behavior-driven)	`Given I have valid credentials` `When I log in` `Then I see the dashboard`	• Tests written as human-readable Gherkin scenarios • bridges developers and non-technical stakeholders.
Test pyramid	`~70% unit / ~20% integration / ~10% e2e`	Guideline for test ratio: many fast unit tests at the base, fewer slow e2e tests at the top.
Smoke test	`@pytest.mark.smoke` `def test_app_starts():`	• Fast sanity check that critical paths work after a deployment • run as a subset of the full suite.
Regression test	`def test_bug_1234():` `assert fixed_behavior()`	• Verifies a previously fixed bug has not reappeared • every bug fix should have a corresponding test.

Table 2: Testing Frameworks

Framework	Example	Description
pytest	`def test_addition():` `assert add(2, 3) == 5`	• Modern framework using plain `assert` • automatic test discovery, powerful fixtures, extensive plugin ecosystem — the current industry standard.

Table 3: Test Discovery and Execution

Pattern	Example	Description
test file naming	`test_.py` or `_test.py`	Files must start with `test_` or end with `_test.py` for automatic discovery by pytest and unittest.

Table 4: Assertions

Method	Example	Description
assert statement	`assert result == expected`	Pytest uses plain Python `assert` with automatic introspection — shows intermediate values on failure without any extra code.