Why Bother With Unit Tests?

I still see a lot of scepticism on WHY we should do Unit Tests and if they're really worth it.

Of course, they usually add time to the development cycle. They can be hard to create. Quite often, they seem pointless; Why do I need to check if my TwoTimesTwo() method returns 4? Of course it's going to!

Well, the benefits of Unit Tests may not always be obvious. Often they're disconnected from the problems caused by not doing them. For example, a manager is not likely to blame a Production issue on the fact that you didn't do Unit tests.

Most of the time, if you release some code that performs what it needs to, nobody cares about the quality. However, the people who will care, are those who want to maintain your code later, especially if it ends up being:

  1. You; or 
  2. A violent psychopath who knows where you live

Unit Tests can also help to document code, showing you what it should and shouldn't be doing. They can help you understand it better.

But maintainability still isn't enough for many people.

Personally I don’t think anyone can really understand the benefits of Unit Testing until they've written some, and felt the satisfaction of those green ticks, and the confidence they give you. Your code is now rock solid, nobody is going to break it without knowing about it (including yourself).

With Unit Tested code you can be sure that every component is doing what it should be. Acceptance Criteria is another step and I'm a strong proponent of automated behaviour driven integrated tests too. But Unit Tests can be more granular, covering a vast array of tiny details that can otherwise be easily overlooked and become the source of fiddly bugs later on. Also, when bugs are found, usually this results in messy, band aid fixes which make the code less flexible. TDD makes the code more maintainable to start with. The necessity to write SOLID code is increased by the need to ensure the code is highly modular and interface driven.

In the end, the extra time spent building unit tests is returned several times by spending less time fixing bugs and maintaining messy code.

The best way to see the benefits of Unit Tests is to write some. Start easy by writing one specifically to test a bug fix. You can then be sure that bug will never surface again.

Getting started is hard, don't get me wrong. It's like lifting weights for the first time, it's going to hurt. But push through the pain and you'll start to see the benefits. It will get easier.

Popular posts from this blog

Foundations of Humane Technology - Course completed

Image
Back in January (has it been that long!) I completed the Foundations of Humane Technology course from the Center of Humane Technology . You may have heard of them, they made the Netflix Documentary " The Social Dilemma ". If you haven't watched the movie, it's well worth a watch, delving into the often devastating impacts of Social Media. The course explored how to build technology in a more responsible way to minimise the harmful consequences of the technology you build. It's perfect for technology oriented Product owners and developers like myself, requiring us to think about externalities and unintended consequences, and aligning our values with the products we build. I was made to reflect on how technology has impacted me personally, and realised how my health, cognition and attention were impacted by technology overuse. I was obliged to acknowledge that I am very privileged and lucky, I don’t have any major accessibility issues and my demographic allows me t
Read more

Writing Good Acceptance Criteria

Image
As discussed in my last article , Writing good Acceptance Criteria gives the Agile team clarity and helps them work towards a common goal, saving time and effort while increasing quality. Now I'd like to dig into the details of how to write good Acceptance Criteria. Behaviour Driven vs Procedural Driven Mindsets Many of us may be used to writing/seeing procedural driven tests; step by step instructions with actions and expected results. Procedure-driven tests are often imperative and trace a path through the system that covers multiple behaviors. As a result, they may be unnecessarily long, which can delay failure investigation, increase maintenance costs, and create confusion. Acceptance criteria, and indeed Behaviour Driven tests, should instead be behaviour driven. This means they should be Declarative , specifying how a system should behave in a particular scenario. Procedural/Imperative: Given the user opens a web browser And the user navigate
Read more

Story Points are Utter Nonsense

Image
For over a decade, I've lived a lie. I made myself believe that Agile Story points made sense. I rationalised it like we all did. "They map to complexity, not time". Yet we spend hours on Sprint Planning meetings deciding how many jobs we can fit into a Sprint - a unit of time . Also - doesn't complexity relate to time? "They're a rough guide, they're not supposed to be accurate." How on Earth did we end up with a unit of measure that is "not supposed to be accurate"? "It depends on experience of the person doing the job." This is like saying the length of a centimeter depends on the tape measure you're using. "They're a measure of  relative complexity." Relative to what? Another story you did which didn't have an accurate estimate? "We use shirt sizes/Fibonacci/animals/fruit." Is this supposed to make it easier to understand? Why can't I give a task 4 points? "We have to agree on size befo
Read more