Real pytest: fixtures, parametrize, and Ape's own test plugin#

← Back to Weeks

Full context: root README, After Jenesys.

TL;DR#

This is an optional module, not a required week. It exists because the blockchain track already told you, in Week 7, why a test suite matters and had you write a couple of loose assert statements to prove it; it never showed you the actual tool professionals reach for, pytest itself, as a framework with real mechanics of its own.

  • Weeks 5 through 7 taught the concept of testing (see weeks/07-low-scaffolding-continued/blockchain/notes/02-why-tests-matter-here.md, or its Vyper twin) and had you write one small, standalone test function. That was deliberately minimal: the point at the time was the idea, not the tool.
  • This module is the tool: test discovery, fixtures, @pytest.mark.parametrize, and specifically Ape's own pytest integration, the ape test command and the accounts/project/chain fixtures it wires in automatically, along with the snapshot-and-revert isolation it wraps around every single test.
  • Four short notes, two small standalone exercises, then the real target: a proper tests/test_asset_registry.py added to your own Week 5 through 7 project (whichever track you built), not a new project built from scratch.
  • Nothing here is specific to Solidity or Vyper. The mechanics of pytest and Ape's plugin are identical either way; only the exact function names you call in the project step differ (register_holder vs registerHolder, and so on).

Why this exists#

Look back at weeks/07-low-scaffolding-continued/blockchain/notes/02-why-tests-matter-here.md (or the Vyper track's near-identical version at weeks/07-low-scaffolding-continued/blockchain-vyper/notes/02-why-tests-matter-here.md). That note makes a real, honest case for testing on a solo, ungraded project, and has you write one test proving a specific property (redelivering an event doesn't process it twice). It explicitly says "pytest or unittest, either is fine," and never goes further than one bare assert inside one bare function. That's the right scope for Week 7, where the point is the concept, not the tool.

What that note (and the rest of the program) never covers is pytest as an actual framework: how it finds your tests without you registering them anywhere, what a fixture is and why dependency injection by parameter name isn't magic, how @pytest.mark.parametrize stops you from copy-pasting the same test five times with one number changed, and, specifically for this track, how Ape's own pytest plugin turns ape test into something that hands you funded accounts and your compiled contracts for free and resets the chain back to a clean slate after every single test. That's a real, nameable gap, and it's the one this module closes.

What this covers, and what it doesn't#

Covers: pytest fundamentals (test discovery, plain assert rewriting, running pytest and reading its output), fixtures (@pytest.fixture, dependency injection by parameter name, scope, sharing fixtures across files with conftest.py), parametrize, and Ape's pytest plugin specifically (ape test, the accounts/project/chain fixtures, and the automatic snapshot-and-revert isolation between tests).

Doesn't cover: mainnet-fork testing (there's no organic use case against AssetRegistry, since it has no external contract dependencies, and this was deliberately left out rather than forced in); mocking frameworks beyond what Ape already gives you; coverage tooling (pytest-cov or similar); wiring any of this into a CI pipeline; property-based testing (hypothesis); a second, separate pass at "why testing matters," since Week 7 already made that case and repeating it here would be redundant. This module also isn't a second copy of Weeks 5 through 7: it adds tests to the project you already built, in whichever track you built it, rather than having you build anything new.

Goal#

Real, idiomatic pytest fluency, specifically as Ape uses it, so you can write and run an actual test suite against a deployed-style contract project instead of the one loose assert function Week 7 asked for.

Do this in order#

  1. notes/01-pytest-fundamentals.md
  2. notes/02-fixtures.md
  3. notes/03-parametrize.md
  4. notes/04-ape-and-pytest.md
  5. project/README.md, the real target: a real test suite added to your own Week 5 through 7 project.

Optional, before or after step 5, any order: the two isolated exercises in exercises/, a smaller rep of a single idea (a fixture, a parametrized test) if you want practice on something small before or after the project.

Status#

Notes, exercises, and the project spec are written. There is deliberately no solutions/ folder for the project step, the same reasoning as every other project in this curriculum: writing real tests against your own real project is the point, not matching a reference answer.