A few weeks ago I gave a free day of training to members of the Central Florida Web Developers User Group on ColdFusion's ColdBox framework. The training was a success. Everyone recognized the benefits of the framework and embracing the design patterns shown. In fact, one member who manages a site that yields 150,000 visits monthly has started to convert their existing spaghetti site to the ColdBox framework. The features of the ColdBox framework that stood out to those who attended were debugging, caching, plugins, interceptors—and testing.
I have been asked a lot about unit testing recently from those in our User Group as well as those at my work. These questions have spawned this post which I hope helps you embrace unit testing. I use ColdFusion 9, MX Unit, MockBox and the MX Unit Plugin for Eclipse.
Why unit test?
Unit tests can help you improve the quality of your code by discovering defects quickly. Unit tests can help you feel more confident about the code your write since you are constantly running automated tests against your code.
This paradigm shift can be quite extreme for the developer (I should say most developers) who follow the 'I need get this code written' development process which probably goes something like this:
The "I need get this code written" development process:- Write the software to do something
- Run the software
- Tweak the software until it works
- Repeat
If you are new to unit testing you may find yourself in a new paradigm. If you embrace unit testing, and the test driven development process, your development process will be something like:
The "Test Driven Development" process- Think about what my software needs to do
- Write a test to confirm my software behaves like I think it does
- Run the test expecting failure (since I wrote the test before the software)
- Write the software
- Run the test expecting the test to pass
- Fix any bugs you discovered
- Repeat
Why unit test? Trust but Verify.
You (the developer) are always going to pay if you want good (hopefully great) software that works. I am not talking about money; rather, I am talking about time. We all want software that 'just works'—the difference is those who build good tests can verify their software 'works as expected'. Too often, developers who build software 'that just [barly] works' place the burden of verifying the software works as expected on others. To get software that works as expected before you release it to production all you need to do is write some unit tests. The bottom line is, unless you abandon the software after release you are going to end up spending the time eventually. Why not just invest up front and reduce your surprises? After all, no one in business likes surprises.
Why unit test? Avoid surprises.
Speaking of surprises, have you thought about how things change in your environment or business? Unit testing allows you to automatically test all your software. This means that developing and testing your current work allows you test your previous work without wasting time clicking around.
A Real World Example Of Testing
In January, 2010 Steve Jobs announces the iPad and that AT&T will have an unlimited data plan. If you had written a unit test you could have verified this expectation (or assertion) and been notified instantly the statement became false.
- The Test
- "Hey AT&T, I'm buying an iPad. I expect you have unlimited data plans?"
- April, 2010 Result
- Yes. Test Passed
- May, 2010 Result
- Yes. Test Passed
- June, 2010 Result
- No. Test Failed
Lastly, are you ready for unit testing?
If you are not writing object oriented code you are not ready for unit testing. Reach out for help to learn object oriented programming.
So, you are ready? Get Started!
Fantastic! Continue reading this series...
