3Pillar Global’s SVP of Engineering, Jeff Nielsen, talks about the agile best practice of using Automated Unit Tests, which allows agile teams to incrementally and repeatedly deliver reliable software products.
The one time in my career as a professional programmer that I took a quantum leap forward in my confidence and in my maturity was the year that I learned to use test driven development and started writing automated unit tests for all of my code. That’s what we’re going to talk about today – automated unit tests. And just to be clear, the unit test is a test that tests the smallest bits of the codes so the individual methods and classes – for example an object – array in a programming language. An automated unit test is written in the same programming language as the code itself and runs using a framework like J-unit for Java, and unit for any of the .NET languages. And you write and run these tests at the same time that you are writing your code. It’s not two separate activities, it’s all done together. And like I discovered in my own experience, having automated unit tests for your code and writing those tests along with the code is very, very, very powerful.
One of the reasons it is so powerful is because a good set of automated unit tests function as a type of second compiler for your code. The regular compiler – the syntax compiler – tells you if you have accidentally left out a semi-colon or misplaced a brace and you get that feedback right away so that you can fix all those problems and it is very easy these days to produce syntactically correct code. It would be foolish for anyone to work without a compiler like we used to have to do in the punchcard days. But it is almost as foolish to work without a set of automated unit tests because automated unit tests function like a semantic compiler for your code. They let you know right away if the behavior of the code has changed in some unintentional way if the code that used to do this no longer does that thing that you expected it to do. And it tells you that about your own code while you are writing about the code that you wrote last week or about the code that someone else wrote that you are having to work with today.
That’s why automated unit tests are so powerful because they give you that compilation type feedback instantly. Now that is true if you keep your tests fast, meaning you’ve got to be able to run hundreds, thousands of them in just seconds if you keep them well-maintained. Just like a broken window in a neighborhood that doesn’t get fixed, as soon as people start letting tests go unfixed, pretty soon no one starts to care and all of a sudden we have lost the value of having our automated unit tests. So fast and well-maintained is key for unit tests to function as the semantic compiler like we have talked about.
We require automated unit tests on all of our projects for a couple of reasons. First is that it provides this safety net. It lets you know when you have accidentally done something you didn’t mean to do, you have unintentionally changed the behavior of a piece of code. Bob Martin talks about automated unit tests being like double entry bookkeeping, so my assignment for you is go Google for that. Go figure out how automated unit tests prevent errors – human errors – in the same way that double entry bookkeeping prevents human errors in accounting. So there’s this safety net. Second, they speed you up because you are taking away all the future debugging and testing by hand time, even though it feels like you’re going a little slower having to write test and code at the same time. It speeds you up not just on the course of a project but even over the course of an iteration or a single day’s worth of programming. It’s like cleaning the kitchen as you cook instead of leaving a whole bunch of dirty dishes and then having to come along and try to cook in that mess. Having a set of automated unit tests is good hygiene for your code. And this is…I guess the third point that I will make about that is that it really is impossible to work incrementally without an investment in automation except with all but the very smallest programs and the very smallest systems. It is impossible to continually be adding features to that code in an incremental fashion and keep it in a production-ready state without a heavy investment in automation. You just can’t do it. There’s too much work involved in manually regression testing everything, manually building – we have got to have automation to work incrementally. And the linchpin of that automation as far as I’m concerned is automated unit tests. You have to have them, otherwise you might think you are working incrementally but you are deferring a lot of testing and debugging work until later. If you are a programmer and you are not writing automated unit tests for your code, please start today.