TG: Programming: Unit Testing - Introducing Tupitsa

Home - Programming - Unit Testing

On one of the jobs I was part of, there was a senior developer that I used to butt heads with. We'll call him Tupitsa. He was a highly talented coder, when he wanted to be. Unfortunately for us all, when pulled into the project to implement the next flagship product for the company, he was butt hurt that he wasn't heading up that project -- I was -- and he decided to do the worst possible job he could. But that's a story for another time...

One of the thing we used to argue about extensively was the need for unit testing. If you've been coding all your life without doing any automated unit testing, it first seems tedious and unnecessary. But there's a light bulb moment that happens when you A) find a bug that has been an elusive target for some time, B) when you make changes that create bugs that you wouldn't have found right away because they're happening in an area of the system that your change indirectly affects, C) you can do a monumental amount of retesting just by clicking a single button, and/or D) you catch a bug that someone else created when they based their tests on an incorrect assumption. It can also make it extremely easy to find performance issues, memory issues, problems with order of operations, etc.

Tupitsa came at it from a point of view of sheer laziness. He felt he was being forced to do twice the coding; one set of code to create a function, and one set of code to test it.

I was the architect on the job, but I didn't want to have to say, "Because I told you so." Instead, I made it clear that he wasn't doing twice the job; what he'd been doing up until now was half the job. He was coding, but not testing properly. And the requirements for the job were that he do the whole job, for the sake of the team, the company, and the quality of the product.

That stopped Tupitsa from arguing for the time being, but it didn't convince him to build unit tests because, with those tests, we could have caught his sabotage earlier. But again, that's a story for another time....