Test Driven Benefits

I've written many times about the virtues of unit testing, first and foremost because its the best way to prove that code works as expected.

But as with many aspects of good development practices if you do the right thing you'll profit from many additional benefits.

This is also true with unit testing, its the right thing to do, and as well as verifying your code is fit for purpose it can be the mechanism for other good things to happen.

Consumers First

Code is written to be consumed by others, and the very first consumer is your unit tests. Its your chance to both document how your API is intended to be used as well as place yourself in the position of being a user of your code rather than the producer.

Unit tests can be used a design tool, as your writing your tests always be assessing does this make sense, pay attention to things like how much set-up and tear down is needed, does this represent state that will not be obvious to someone trying to utilise this class?

Unit tests are very good documentation, they not only demonstrate the code being used they also state expectations on the data that should be fed in and the data that will be fed out. 

Shrinking the Circle

Every developer has been on the treadmill of making a change to some code, deploying that code, interacting with that application, finding that bug is still their and back round to the start.

This is dull and inefficient, it might be several minutes before any modification can be verified and on a tricky pest of a defect might be a cycle that is repeated all day.

Unit tests are a very good debug tool, a bug in a class that manifests itself in your application should also be visible in your unit tests, if its not you need to write more tests.

Using your unit tests to find a problem will give you much quicker feedback on the impact your changes are making, if the tests are well written it also helps isolate the code that may be causing the issue, your able to ask more precise questions, does this class do the right thing in this situation?  

The What-Ifs

The infrastructure in your unit tests that ensures your mocking dependencies and decoupling your classes reveals your architecture, whether good or bad.

There is a lot of knowledge to be gained by looking at what tests break if you make a change, if we make this change a lot of tests in many different areas of the code base break, why is that and does that indicate we need to make a change?

It also allows you to speak with confidence if your asked a what-if question, we're thinking of adding this feature or making this change, the scale of that work will often be linked to level of decimation it will cause in your unit tests.

Following principles like single responsibility and open-close should ensure that changes don't cause carnage in your unit tests, you'll always be adding more unit tests but are you constantly having to re-write the ones you already have?

Hopefully everyone is realising the benefits of automated testing, and if the only benefit your drawing from it is the automatic verification that your code still works then its been worth it but be open to the fact that there is a long list of other benefits to be plundered.

This is just one example that if you do the right things good code will happen and you'll expunge less energy and brain power in producing it.