7 Reasons Why Unit Tests are Valuable

Do developers like Unit Tests? Do they find them valuable? Today's post shows why unit tests are considered valuable to developers and why they should write them

With the latest Cross-Cutting concerns podcast, Matt and I discuss the StackOverflow Developer Survey 2019 Results.

In the podcast, I mentioned how developers said companies don't implement unit testing, but developers see the value of it.

This is good news for the industry: developers see value in unit tests. This survey is proof of that, but there are some developers who still may not see it.

So I thought this would be a great time to list the various reasons why unit tests have a lot of value to developers. 

7 reasons, actually.

1. It provides a "checks-and-balances" approach

If you write complex application code, you need some way to confirm your code actually works.

Yes, yes, I know, you can test the code when you run your application.

I get it, Mr. "Chuck Norris."

But writing unit test scenarios provides a better way to prove to you (and possibly your customer and/or product owner) that you have a stable and reliable piece of software.

2. It's the modern way to write a "Console app" as a tech spike

I remember (before unit tests) how a number of developers (including me) would create a simple Console app outside of the project to confirm whether an idea would work or not. You would write a small app to see if something was possible.

Well, guess what? That's what Unit Tests prove out.

Not only does creating unit tests confirm that a "programmatic hunch" actually works, it builds on a simplified prototype making it an easier transition to production code.

3. It's the standard way of writing code

As mentioned in the podcast with Matt, developers are writing unit tests more and more.

I would like to think when the higher-ups say "don't do it, it takes too much time", developers don't care and write them anyway (It's not their head on a chopping block).

Developers are seeing the value in writing unit tests and are moving forward with it because it confirms their code works instead of flipping a coin and pushing it out to production.

It's how professional software is meant to be written.

4. It provides documentation for the next developer

There were times when I didn't know what the heck a piece of code did in a given system.

Granted, I've been around a lot of code in my career, but for someone new to the scene of programming, they need some hand-holding to understand what is happening.

It makes sense to write a series of unit tests to follow the path of how developers came to such a "code conclusion," or why they decided to write code this way.

It's probably the next best thing to a comment; seeing how it runs with a code snippet.

5. It proves the design of the application

If you have something granular enough, ANY programmer should be able to look at a unit test and immediately understand what action and behavior is being performed and returned, respectively

Your unit tests should prove the application is shallow enough where you can pick a section in your production code and mimic it with little to minimal setup in the unit test.

This proves two things:

• Your code is decoupled; granular
• Your application is simplified and composable.

Simplified unit tests give developers a solid understanding and overall good feeling of a well-written application.

6. Refactoring with confidence

I mentioned this before when I rewrote a business rules/validation engine. We had over 500 unit tests in place for this engine. We found an issue where we had to rewrite a certain section of code, but the fix had a ripple effect. A refactoring had to occur.

I started refactoring while running the unit tests after each refactoring (standard practice according to Refactoring, 2nd Edition). I refactored the application in 3 days. At the end of those three days, I had one unit test not passing because I renamed a property.

If it weren't for those unit tests in place, I would be writing code blindly and not knowing what I broke.

If you do refactor code, unit tests provide confirmation that the functionality continues to work as expected while writing better software.

7. Reliable Continuous Integration (CI) Pipeline

If you work with a team of developers, you know when someone breaks the build.

It happens based on one of two reasons:

• Someone didn't refresh their code and checked in their changes (ALWAYS get latest before checking in)
• Someone modified a piece of code you worked on and triggered one or more unit tests to fail on the build

Unit tests give teams a certain confidence level when they see green in their CI builds. If they see green, everyone breathes a sigh of relief.

If not, we string the culprit up by their fingers!

Just kidding (no, really...we do).

Conclusion

Unit tests have come a long way and is now considered the standard when writing software.

If you don't have unit tests for an application, whether the project is "Green Field" or legacy, most developers raise an eyebrow and slowly back away from the code.

They don't want to work on the system for two reasons: they're afraid they'll break something and get blamed for it...

..or they won't be able to sleep at night anymore from the nightmares.

Do you use unit tests? Do you consider them valuable? Why do you use them? Post your comments below and let's discuss.