🥼
Building testable systems
Build it well and build it to be testable.
Before we even try to test something, the system itself has to have some basic qualities so it can be deemed testable at all. I will continue to refer to the system as an API: It doesn't have to be a web API, as the term should cover many common types of systems.
This section picks up on those things you can (and should) do as a developer before even spending any time on the testing itself.
- 1.APIs are Forever
- 2.Never Break Backward Compatibility
- 3.Work Backwards from Customer Use Cases
- 4.Create APIs That are Self Describing and Have a Clear, Specific Purpose
- 5.Create APIs with Explicit and Well-Documented Failure Modes
- 6.Avoid Leaking Implementation Details at All Costs
Good code has many qualities that are often spoken of when discussing what "good code" actually even means. Commonly mentioned qualities include being readable, maintained, organized, and structured, and following reasonable semantic naming conventions.
For us to build something that is testable at all, the code, therefore, needs to be of a certain level. In this section, I'll go into some of what might go into that.
In this area, some relevant literature includes:
Last modified 5mo ago