David Rodenas PhD
2 min readOct 7, 2023

--

Oh That sounds amazing! Now I'm jealous ;-)

In short, what Uncle Bob (and Kent, Ward, ...) understood as a Test Unit it was a test to test a behavior, not an isolated part of a system, they did not conceive it to test an isolated part. And the opposite is true for Jim, he only understood Unit Test as something to test isolated code.

That is specially relevant when we take into consideration that Kent and Ward define a Unit Test as a test of one Unit of Behavior [1] [2] —not Unit of Code—, and Kent Beck is who created the firsts XUnit testing tools [3]—including SUnit and JUnit. So, when they said that these tools are for Unit of Behaviors, they meant that they created those tools with that objective.

Sadly, inside the waterfall model, the tool was also taken to test unit of code, and somehow this application became more popular.

But the reason why Bob, Kent, Ward, ... used testing was to help them to keep the code agile: scalable and malleable. That is why they did not conceive the testing of code itself because it would prevent any future change. Yet, if you listen to Jim —or to DHH— they complain that Unit Tests damage their code, forcing too much isolation, and preventing future change. Both definitions —and objectives— are opposed to each other.

Each of both sides have their own ways to understand testing so rooted inside their heads, that they cannot understand why the other part says what they say.

Every time that I see the video of Jim and Bob, I want to scream and tell them that... but even if I got as lucky as you to be there, probably I would be at the side of Jim, because like them in the past, I felt testing and TDD stupid, because I followed the wrong definition.

--

--

David Rodenas PhD
David Rodenas PhD

Written by David Rodenas PhD

Passionate software engineer & storyteller. Sharing knowledge to advance our skills. Join me on a journey of discovery in the world of software engineering.

No responses yet