I test therefore I code: Intro

This is the first post of a series of articles, where I'm going to talk about developer testing, why I think it's important and its practical application in Java programming.

For this first article I was prepared to start quoting books about what developer testing is and start laying a foundation for next deliveries, but then I reconsidered and decided to take another approach. I'm going to tell you why I like developer testing and why I think it deeply impacts the quality of the software we write.

A few years back I didn't practice any automated or methodical developer testing. When I would develop new features or fix bugs I would go through the system manually exercising the features that I thought would be affected by the changes I had made to the code base. Unsurprisingly I would always miss something, maybe I would fail to see the relation between what I was doing and some feature in the system or maybe I would test something new, think it was completely functional then make (what I thought would be) a harmless change and then all Hell would break loose. I hated when that happened, because not only it meant more work for me, but it also meant that something I would deliver as working would then be tested by the QA team only to find more bugs related to my changes. Now you could argue that I'm a terrible developer who doesn't know how to properly do his job, and you might be right, but in any case I knew there had to be a better way of doing things.

A couple of years ago I was lucky enough to work in a project with a company that encourages automated developer testing and even worked with a group that embraced TDD as their development methodology. It was then when I realized the benefits of having a good, fast, automated suite of tests that would exercise your code as isolated units and as a whole system. To me the main benefits I got were:

• When I created a test for a certain feature, I would use that time once, then I could move forward knowing that I just had to run that test to make sure the feature still worked.
• I had a safety net when refactoring the code. The test suite would become a baseline for functionality, so I wasn't afraid to change code.
• Immediate feedback. When I created a certain piece of code, I could test it, even if the UI or the backend were not finished.
• Finishing criteria. When I wrote the test first, I knew exactly when the code I was working on was finished, when the test passes then you are done.
  
• Better architecture. Testability would influence the architecture. When you are writing your tests you want to be able to set them up quickly without having to wire too many dependencies together, which makes your components loosely coupled, then you want to test very specific behavior making your components highly cohesive. That alone will make your code better and more flexible.

I think the previous points make developer testing absolutely worth it and when done right it can lead a software development team to attain much better quality standards and the business will save money in the long run, but most importantly it gives you peace of mind and that, to me, is something invaluable.

I'm my next post, we'll dive a bit more into the definitions of developer testing and then we'll get hands on to its application to Java development.