QA-Unit Tests vs. Agile-Unit Tests

The definitive guide to understand how much different Agile testing is from traditional testing.

Recently, I published an article mentioning the existence of two kinds of unit tests: Agile-Unit Tests and QA-Unit Tests. Unfortunately, this naming is mine, and although both techniques have very different focuses, the practitioners of each one use the same term for both of them: “Unit Test”. That leads to lots of misunderstandings and problems. And it also makes very hard to learn the other one. Specially the Agile-Unit Tests. In this article, I will talk about the different kinds of tests, what are each one good for, and I hope to help you to understand the value of each one.

Living The Misunderstanding

But, before starting, I want to show you a conversation between Jim Coplien and Robert C. Martin in which they cannot communicate because each one give a different meaning to Unit Test. One is a practitioner of QA-Unit Tests, while the other is a practitioner of Agile-Unit Tests (note that Robert C. Martin is one of the creators of the Agile Manifesto). The video is old (and the quality bad), but it was a response from Jim Coplien to Robert C. Martin about the need of following TDD as an ethical principle for every developer.

The context of that time relates to the fact that Robert C. Martin is continuously searching for an equivalent of the Hippocratic Oath for the developer. He is looking for that something that will get the best effort from the developers, and at the same time, will protect them if anything goes wrong (at least they tried their best). His first try were the SOLID principles. But when he discovered TDD, he realized that SOLID was not enough, so he wrote the three rules of TDD as the oath that all developers should take (note: nowadays, he has continued this task). The problem was, while the SOLID principles were very well received, the same did not happen with TDD, and a lot of opposition was created.