docs(articles): refine testing-telos draft for clarity and flow

- Remove redundant subtitle and reorganize introduction
- Simplify language around "telos" and rephrase key sections
- Update diagnostic question and conclusion for better readability
This commit is contained in:
Gregory Gauthier 2026-04-17 12:04:34 +01:00
parent 1396de6a7e
commit 9af411d6c8

View File

@ -1,12 +1,8 @@
# Testing Telos # Testing Telos
**A shape for every purpose; a purpose for every shape** The classic *Testing Pyramid* is not wrong; it is simply *incomplete*. It was forged for one specific kind of engineering work: the steady addition of new user-facing features. In that narrow context the pyramid makes perfect sense: a broad base of fast, cheap unit tests, a smaller middle layer of integration tests, and a thin apex of end-to-end checks. The shape itself is the visual signature of a particular *telos*—the final cause or purpose—of that work.
The classic *Testing Pyramid* is not wrong—it is simply *incomplete*. But software engineering is not a single kind of work. Different engineering goals demand different testing strategies. The pyramid is only one of four natural shapes that emerge when we observe what teams actually *do* in practice. Each shape is the visible expression of a distinct *purpose*.
It was forged for one specific kind of engineering work: the steady addition of new user-facing features. In that narrow context the pyramid makes perfect sense: a broad base of fast, cheap unit tests, a smaller middle layer of integration tests, and a thin apex of end-to-end checks. The shape itself is the visual signature of a particular *telos*—the final cause or purpose—of that work.
But software engineering is not a single kind of work. Different engineering goals demand different testing strategies. The pyramid is only one of four natural shapes that emerge when we observe what skilled teams actually *do* in practice. Each shape is the visible expression of a distinct *telos*.
In Aristotelian terms, testing is *techne*—a craft. A craftsman does not begin with a fixed form and force every material into it. He begins with the *purpose* the artifact must serve, then lets the material and the method follow. The testing strategy is the form; the engineering goal is the telos. When the two are mismatched, confidence is illusory and effort is wasted. In Aristotelian terms, testing is *techne*—a craft. A craftsman does not begin with a fixed form and force every material into it. He begins with the *purpose* the artifact must serve, then lets the material and the method follow. The testing strategy is the form; the engineering goal is the telos. When the two are mismatched, confidence is illusory and effort is wasted.
@ -72,15 +68,15 @@ What follows are the four archetypal testing shapes we have observed across real
A mature testing practice begins with a single diagnostic question: A mature testing practice begins with a single diagnostic question:
> *What is the purpose (telos) of the work we are about to undertake?* > *What is the kind of work we are about to undertake?*
The purpose we're concerned with here is the *kind of change we want to make* (regardless of the product delivered). Answer that question honestly, and the appropriate testing shape reveals itself. Trying to force a star-shaped concern (e.g., a security audit) into a pyramid-shaped strategy produces either massive waste or dangerous blind spots. Conversely, treating a simple feature addition as a diamond-shaped structural migration inflates effort without improving outcomes. When we undertake a set of changes, we typically already have some understanding of what the ultimate purpose is: the delivery of some final service or product. To know what testing strategy to use, we need to know what *kind of change* we are about to make, to that end. It turns out that the end will typically reveal to us the appropriate testing shape. Some end goals are single features. Some are infrastructure upgrades. Some are security improvements. Trying to force a star-shaped concern (e.g., a security audit) into a pyramid-shaped strategy produces either massive waste or dangerous blind spots. Conversely, treating a simple feature addition as a diamond-shaped structural migration inflates effort without improving outcomes.
The shapes are not mutually exclusive. A single release may contain work that belongs in more than one category. The craft lies in recognizing the dominant telos of each piece of work and allocating testing effort accordingly. The shapes are not mutually exclusive. A single release may contain work that belongs in more than one category. The craft lies in recognizing the dominant telos inherent in each piece of work and allocating testing effort accordingly.
## Conclusion ## Conclusion
The Testing Pyramid was never meant to be a universal law. It is one elegant expression of a deeper principle: *testing strategy must be purpose-driven*. By making the purpose (telos) explicit and giving each purpose its own visual signature, we move from mechanical rule-following to genuine craftsmanship. The Testing Pyramid was never meant to be a universal law. It is one elegant expression of a deeper principle: *testing strategy must be purpose-driven*. By making the purpose explicit and giving each purpose its own visual signature, we move from mechanical rule-following to genuine craftsmanship.
A shape for every purpose. A shape for every purpose.
A purpose for every shape. A purpose for every shape.