Learn the concept
Build the capstone incrementally. First parse and validate one record. Then process a collection while preserving individual failure outcomes. Add storage only after the transformation behavior is tested. Finally connect the CLI and report writer.
Use parameterized SQL, a unique document ID, and a transaction for each defined atomic unit. Do not leave the database claiming a document was processed if the corresponding required operation failed. If the report is generated separately, describe that boundary and how it can be regenerated.
Test with temporary files and a fresh database. Run the same input twice to check idempotency, then change a source version to test updates. Keep the application usable without network access. This assignment is a build specification, not a hidden dependency on an external course.
Run and inspect
expected_summary = {"accepted": 5, "rejected": 5, "total": 10}
assert expected_summary["accepted"] + expected_summary["rejected"] == expected_summary["total"]
Your exercise
Implement the CLI from the previous lesson. Add unit tests for validation and integration tests for file-to-database processing and repeated runs.
Check your understanding
The summary reconciles all input records, repeated runs do not duplicate data, and failures leave understandable recovery steps.