Why unit tests are great for peace of mind

As a fledgling software developer I have been inundated with tips, style advice and best practice information from every which way from people who have been in this field for years and have incredible amounts of experience to draw upon. Of course, all of this has been on top of wrapping my brain around a large code base, with multiple contributors in languages I had minimal experience with before my internship started late last year.

My experience with unit testing so far

Coming into this company with a large code base and a lot of smart people involved, customers and coworkers alike, I was very nervous about the eyes on me and my pieces of code. I was and still am nervous about code reviews, having not been exposed to them before. At university, we touched on JUnit testing for one of our assignments, but the usual test fall back was the ol’ black box test, see if it spits out the right output with the given input and jobs a good ‘un, hand it in five minutes before the due time. Needless to say, real world coding is a little more accountable and forces you to grow up or get out.

I’ve gone through the process of developing large amounts of code without unit tests and relying on black box testing only and it made me regularly uncomfortable. Mainly because the human element of coding has not been eliminated and people still make mistakes – we all have those early morning morning/late afternoon Friday brains that seem to plot against us.

Unit testing eased this paranoia that I had missed out some vital logic flaw or manipulated the wrong data.

So that all of us are on the same page, unit tests are essentially bits of code that have the sole purpose of testing another piece of code that you have written as part of a new feature, for example. Off the bat, this sounds like it would be a great way of ensuring that the swish new feature you have just developed is bug free, right?

But wait, there’s more.

Not only does it check the code that you have written, but pre-existing tests for the grand-daddy code base can ensure that the integration of your feature isn’t going to fluff up some vital functionality of your product or application. A new user interface or API integration is all well and good but not so much if you bring the whole thing down.

Is it really worth it?

In some instances, a feature may be hard to test in the sense that a lot of it includes a lot of client-side interaction and you may think to yourself, why on earth should I go to all the trouble of mocking up all sorts of states to test 20 lines of code? If there is a risk that those 20 lines of code could do the slightest bit of damage to an already functioning and successful application, those tests could save you from having to wear the code cone of shame when your co-workers find out that your lack of unit testing prevented a piece of core functionality. But that call is really up to you and your boss.

I’ve had many people talk to me about unit testing and some completely hate it. Not just because it can be tiresome and dull to write, but also because it shows them that part of their creative little code baby is wrong. While a bunch of red failure notices can be disheartening, the satisfaction of that gorgeous green tick of one in many unit tests can make it a little easier and a little more satisfying knowing that that tick is one less error you’ll be getting from us 😉

I’ll be back to talk about how to go about writing these pretty little code saving unit tests next time.

Until then,

Assert.That(blogPost, Is.Finished);