The real reason [acceptance tests and unit tests] aren’t redundant is that their primary function is not testing. The fact that they are tests is incidental. Unit tests and acceptance tests are documents first, and tests second.
Chapter 7, Acceptance Testing, The Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. Martin
As my wife and I were listening to Uncle Bob’s book on professionalism in software, this line surprised me. Maybe it’s just because [I don’t understand tests as well as I’d like](https://kerrick.blog/articles/2025/confessions-of-a-software-developer-no-more-self-censorship/ “Confessions of a Software Developer: No More Self-Censorship”…
The real reason [acceptance tests and unit tests] aren’t redundant is that their primary function is not testing. The fact that they are tests is incidental. Unit tests and acceptance tests are documents first, and tests second.
Chapter 7, Acceptance Testing, The Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. Martin
As my wife and I were listening to Uncle Bob’s book on professionalism in software, this line surprised me. Maybe it’s just because I don’t understand tests as well as I’d like, but I had to stop and take note. He clarified exactly what he meant, too:
Acceptance tests are not unit tests. Unit tests are written by programmers for programmers. They are formal design documents that describe the lowest level structure and behavior of the code. The audience is programmers, not business.
Acceptance tests are written by the business for the business (even when you, the developer, end up writing them). They are formal requirements documents that specify how the system should behave from the business’ point of view. The audience is the business and the programmers.
Chapter 7, Acceptance Testing, The Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. Martin