In this week's episode, I will be talking about a topic that I think is crucial when programming. This important concept was only revealed to me after I had already been programming professionally for 3 years.
Unit Testing in Java
Just this past week I was working on assignment 6 for the blog, and the assignment was to create a Texas holdem poker card game. This assignment ended up being a little more work than I had originally planned for, and that left me scrambling to get all the source code out in time for everyone to enjoy it. I claimed that if it wasn't for the Unit Testing framework I had built in:
- It would have either taken MUCH longer to complete the assignment
- It would have been released on time, but full of bugs
What's interesting to note here, is that this same scenario plays itself out over and over again in a professional environment. You are constantly working under a looming deadline, and when push comes to shove, you end up releasing code that's “done” in terms of functionality, but likely FULL of bugs.
After working in a team of developers as part of the full software development life-cycle for over 5 years, I know the exact cost of releasing buggy software. Here's a breakdown:
- Customer finds a bug and has to report this bug – this is frustrating for both parties
- Someone needs to be there to document the call and send off the bug report to a development team
- That bug needs to be reviewed, understood and prioritized – there could be an attempt to re-create the bug at this point
- The bug will then be assigned to a particular team
- Yet another person will need to review and understand the bug (possibly a team lead) – likely this individual will try to re-create the bug
- If a team-lead reviewed the bug, then it'll likely have to be handed down to yet another team member, the bug will once again need to be reviewed an understood by a developer – The bug will HAVE to be re-created at this point
- The process of re-creating a bug is often the biggest stumbling point for developers, the circumstances behind how the bug presented itself will need to be the same as they were in the customer's environment – this is such a huge pain in the butt, take it from a guy who has had to do this day in and day out
- The process of FIXING the bug can finally begin now
- The bug fix may need to be peer-reviewed
- The bug fix is submitted through a source control system
- Normally a quality assurance team will pick up the change and test to ensure nothing else was broken by the ‘fix'
- Depending on the size of the company, another process of User Acceptance Testing may occur
- Barring the unfortunate circumstance that the bug fix was flagged as inadequate, the bug will be scheduled to be released to the customer at some point in the future
- All the while in this ENTIRE process, everything should be properly documented so that processes can be reviewed and inspected if there are any problems that arise due to a ‘buggy fix'.
Do you know how to avoid the cost of buggy software?
The list of steps above is an absolute nightmare. But it's a very real nightmare that companies have to deal with day in and day out. Entire departments can be dedicated to dealing with bugs. It's a MASSIVE waste of time and money, not to mention the lost opportunity cost of being able to work on business activities that could positively affect the bottom line!
So here's my proposed solution…
SPEND THE EXTRA TIME AT THE VERY BEGINNING TO CREATE UNIT TESTS!
Think about how much time would be saved if a unit test you wrote caught a bug before it even went out to the customer? Think about it! Even if you spent an extra TEN hours creating unit tests for a particular piece of code, and ONE of those unit tests caught a bug. How much of the customer's time would you have saved? How much of your own time and agony would be saved? Your manager? Your team-lead? The QA team? Any QA people working as part of the UAT process?
Here's an interesting one… think of how much time you would have saved if your “bug fix” caused another bug that you failed to catch before releasing it to the customers?
If there's one thing that I'm absolutely convinced about now, it's that unit testing will save you (or your company) time and money. Period. End of discussion.
And do it!