Build and Test the Tool
1. Build and Test the Tool
The plan is ready. Now it's time to build. This video takes the reporter.py specification and turns it into working code, then writes tests to verify every piece works.2. From Plan to Code
The specification from the previous video defined exactly what's needed: three arguments, a database query, and file output in JSON or CSV. Claude has everything it needs. One prompt turns that plan into a complete Python script.3. CLI Argument Patterns
Argparse supports four patterns. Required arguments fail loudly if missing: good for inputs that have no sensible default. Optional ones fall back to a default. Flags toggle behavior on or off. Positionals are the simplest: just a value by position. The discipline: help text on everything, validate at the start, and fail with a message that tells the user exactly what went wrong.4. Building the Reporter
With that foundation in place, here's the prompt: "Use PLAN.md to build reporter.py." Claude reads the specification and gets to work. Here's what it generated: five core functions covering database connection, artist statistics query, JSON and CSV formatting, file output, and CLI orchestration. Notice the extras Claude added without being asked: case-insensitive artist lookup, per-album revenue breakdown, and a db flag for test injection. The plan was the roadmap; Claude made good decisions along the way.5. The Generated Code
The generated code is complete and ready to run. Argparse handles the required artist argument and optional format. SQLite query via MCP. JSON and CSV output logic. Claude read the plan and made sensible decisions throughout — indentation, defaults, structure — without being asked.6. Test the Tool
The test flow is three steps: reporter.py runs, pytest checks the output, verify the result. The tests confirm a valid artist returns data, the output file gets created, and the format is correct. Same pytest workflow used throughout the course.7. Testing CLI Tools
But what exactly should those tests cover? CLI tools benefit from both test types. Unit tests isolate individual functions: mock the database, test format logic separately. Integration tests run the actual command against the real database. Cover the happy path, error cases like artist not found, edge cases with empty input, and file handling scenarios. That's a production-ready test suite.8. Testing in Action
One prompt: "Use @PLAN.md and @reporter.py to write pytest tests and run them." Claude generates 31 tests across 7 classes: connection handling, artist statistics, JSON and CSV formatting, file I/O, CLI argument validation, and full integration scenarios. It uses a minimal seeded SQLite database, independent of Chinook. Everything passes green. The reporter does exactly what the plan specified.9. Let's Practice!
From specification to tested CLI: that's the full build cycle. Planning paid off — Claude had everything it needed to generate clean, working code. Now it's your turn: build reporter.py from the plan, write the tests, run them green. Let's practice.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.