🥼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.
There's a lot more about this general area in my book Better APIs if you are interested.
This section picks up on those things you can (and should) do as a developer before even spending any time on the testing itself.
Remember Werner Vogels' advice and think of API as a broad concept:
APIs are Forever
Never Break Backward Compatibility
Work Backwards from Customer Use Cases
Create APIs That are Self Describing and Have a Clear, Specific Purpose
Create APIs with Explicit and Well-Documented Failure Modes
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 updated