Teaching Unit Testing


Let’s put aside the fact that teaching is *hard*.

But teaching something like unit testing is double trouble as I believe is one of those things you really have to do by yourself.

Of course I am not saying that showing how basics work and laying out some techniques is not useful, but the trainee will not “get it” until he tries by himself. And I do not mean try for a couple of hours, even a day and off-you-go, you can master it. I mean loong and painful time.

But let us not give the subject more importance that it has (or the teacher, no matter how smart he is). It is not rocket science or neurosurgery, but it has some intricacies that make it not the easiest thing to grasp.

After watching some really good developers scratch their heads and feel despaired when confronted to a piece of code in order to prove it does what it is supposed to (even if it was written by them!!) or feel terribly uncomfortable with the idea of test-first, I finally realize there is a variable I was not considering: The domain of the problem is completely different.

We might think “but… it is just code!!!” and we are right. But if we say so we are failing to notice that what makes this business difficult (and interesting) is not the code, or the technical challenges (at least not 100%, not even 80%), but how those technical skills are mapped and used against the problem at hand. And the problem we are trying to solve when unit testing a piece of code is very different from the one we are trying to solve by writing some code. They are related, but their essence is substantially different.


Let’s consider a “simple” domain, like the one I happen to work most of the time: E-Commerce. We work with concepts such as products, categories, catalog navigation, discounts, line items, purchase orders, etc…  And we twist those concepts and add some new ones in order to fulfill the requirements imposed by our clients.

Now think about some of the concepts that we handle to prove that our solution works as expected: a price property of a displayable object was set to a price in the same currency as the user expects, some sort of notification was fired when an order was completed so that some other process can take place, a given validation service was called with a list of arguments that represent the items inside the basket and it should return no errors for the process to continue, the database layer should throw a given exception when optimistic concurrency is violated, etc… These and some other lower-level and higher-level concepts are the ones that are handled by the developers testing code in the E-Commerce domain. Very different indeed from the aforementioned ones.


And we all should be aware that what it makes developers valuable is not only their technical skills, their ability to work in a team, their leadership features, their will to learn new things,… but their knowledge of the domain they are working on and their ability to apply all those other skill-sets to their given assignment within the domain constraints.

And getting comfortable and effective within an unknown problem domain takes time. And I mean looong and painful time.