Architecture Patterns with Python

Rules of Thumb for Different Types of Test Aim for one end-to-end test per feature This might be written against an HTTP API, for example. The objective is to demonstrate that the feature works, and that all the moving parts are glued together correctly. Write the bulk of your tests against the service layer These edge-to-edge tests offer a good trade-off between coverage, runtime, and efficiency. Each test tends to cover one code path of a feature and use fakes for I/ O. This is the place to exhaustively cover all the edge cases and the ins and outs of your business logic. 1 Maintain a small core of tests written against your domain model These tests have highly focused coverage and are more brittle, but they have the highest feedback. Don’t be afraid to delete these tests if the functionality is later covered by tests at the service layer. Error handling counts as a feature Ideally, your application will be structured such that all errors that bubble up to your entrypoints (e.g., Flask) are handled in the same way. This means you need to test only the happy path for each feature, and to reserve one end-to-end test for all unhappy paths (and many unhappy path unit tests, of course).