The classic reason for unit testing is to prove that the code works as you believe it does. Given an addition method accepting two integer numbers we can assert the output of the method when we know the input. Proving the functionality of our code is the foundation of our testing philosophy because it gives us assurance not only that our code's architecture, engineering, and logic are correct, but also that we understand how that code interacts within the greater system.

As a system evolves, features are added, deprecated, and changed. It's relatively easy for knowledgeable developers to add features. However, it's difficult to safely deprecate features. The highest risk to a system, however, comes from changing the implementation of the given features. This is where unit tests can save vast amounts of time. Imagine being tasked with replacing the implementation of a complex calculateIncomeTax method. The current implementation and the new implementation are functionally identical, but your new method is 5x faster. Because both implementations are expected to function identically existing tests are valid proofs of functionality for both implementations. Because of this, replacing the implementation of a complex method becomes safer and easier. Make a change to the implementation, and so long as the tests pass, you can be confident you've not introduced a bug.

As you start to write unit tests for your code, you'll quickly learn that poorly designed, tightly coupled code is difficult to test. Writing tests to ensure software quality and maintainability, rather than to meet deployment requirements, will force certain design choices on your code. You'll end up with code that is more loosely coupled, with less reliance on state, and is generally simpler. Such code is easier to test, and is therefore easier to functionally prove. Additionally, because it no longer requires maintaining state or tightly coupled relationships with other objects, this type of code is almost always reusable code, which is never a bad thing.

If you're writing software for a living, you're working to solve complex real-world problems, not to prove your understanding of computer science principles. The situations and problems you're tasked with solving are not simple problems, but nuanced, intricate problems complex enough to justify custom software. This can lead to seemingly crazy bugs that are incredibly hard to solve. There are situations where your code fails because of some other bit of code that fails only on the last day of the month or at midnight on Thursdays. I call these Cinderella bugs because they only happen at midnight on the night of the ball. Writing unit tests help you identify these situations before you experience them in production. Granted, you'll need to show some creativity when writing your tests, but learning to test your billing code at midnight on Thursdays is generally the kind of lesson you only need to learn once.

It's a truism that the job you have now is likely not your first, nor your last. Inevitably we will face the daunting task of learning a new code base. On top of that, outside of a computer science textbook, when have any of us ever encountered a code base that consistently followed best practices as well as proper and sensible object oriented abstractions? Indeed. When I was working as a consultant, coming up to speed on a org's code base was a weekly chore. One of the best ways I've ever found to get up to speed is to read through the tests. Well written tests demonstrate not only what the code does but also what kinds of data are expected and required for that code to run. Fantastic tests will even walk you through failure scenarios and their causes. Even badly written tests give insight into what the developer was thinking the code should do.

Even if you only write basic unit tests to prove your code functions as you expect, you've decreased the chances of having bugs in your code. Why? There are a few reasons, but the basic principle is that you're less likely to make a logic mistake in two places than you are in one place. With each test you write, you're decreasing the risk that you've got a logic bug somewhere in the code you are testing. Writing good tests helps by not only exercising your code, but also by helping you think through your code's interaction with the greater system. This is especially true if you write your test code first! Forcing yourself and your team to design new functionality up front causes you to pause and consider what existing code you can reuse as well as consider the impact this functionality has on the greater system.