Write a pyproject.toml and verify it with tomllib
Delete the [project.scripts] section from the text and run again to see the problem list.
Finish docqa like a professional project: a test suite built on fakes, Ruff and a type checker, a pyproject.toml with a console command and a lock file, a Dockerfile, a README, and a list of what to build next.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a unittest test class with two tests for a function normalise(text) that lowercases and strips text, then run it with a TestResult and print the counts.
Use tomllib to read this text and print the project name and version: [project] newline name = "demo" newline version = "1.2.3".
Write a function has_secret(text, secret) and a test showing that describe_config-style output never contains the secret string.
Explain it without notes
How do fakes and dependency injection make the docqa test suite fast and deterministic?
What goes in pyproject.toml, and what does the lock file add?
What belongs in a good Dockerfile for a Python tool, and what must never be in the image?
Which checks would you run in CI for this project, and in what order?
How do pytest fixtures and parametrize improve a test suite compared with plain unittest classes?
Expected output
name: docqa | python: >=3.12
command 'docqa' runs: docqa.cli:main
runtime dependencies: ['numpy']
extras: ['dev', 'openai']
tools configured: ['mypy', 'pytest', 'ruff']
problems: none