Often times I get the sense that others think I'm a nut for testing. There are plenty of others out there who are far more dogmatic about testing than I am. In fact right now I'd be ashamed to share with you the test coverage of our current project. I will say that the old codebase from which we are migrating had 0% coverage and I'm proud to say, confidently, that we're beating that number handily.
Testing, at it's very core, for me, is about ensuring correctness. Whether you're testing using an automated testing framework such as NUnit, MbUnit, or xUnit or you test by hitting F5 and running your project, you're seeking correctness. For the moment forget words such as "Unit Test", "Integration Test", or "System Test". Those terms only indicate different scopes on which you can test for correctness. Often they confuse more than they clarify. They have their place, just not here right now.
I came across the following code the other day:
1: public Address GetBillToAddress()
3: return shippingAddress;
See the problem? Yeah, it was an easy one. This code, as it sat, was not tested. The problem with the code above is that it's so simple that it's easy to think it doesn't need to be tested. Most users use the same billing address as their shipping address, thus masking the error for the vast majority of users. The danger lies in a simple bug like this masquerading as something more insidious. For example, this method is part of the "User" class in an eCommerce application. The application verifies the users credit card by sending credit card information along with billing address to a credit card validation component. We've already said that most users would have the same billing address as their shipping address. However, imagine when a user comes by who has different shipping and billing addresses and now the user is being told that their credit card cannot be validated due to the billing address not matching the address on the file with the card. I see a couple of scenarios happening but two that I want to address specifically:
- In the worst scenario, the user will just go to a different site, knowing their credit card is good and assuming our site is wrong. We lose the sale and are not alerted to the problem on the site.
- The second, less likely scenario is that the user calls our customer service department to tell us the problem. The customer service department verifies the problem and gets in touch with the manager of the eCommerce department. The eCommerce manager verifies the problem as well and gets with one of the developers to find/fix the problem. The developer then begins to research the problem and may find it immediately or may start looking in the wrong place, the credit card authorization component.
While I'm being a bit overly dramatic here, it's for good reason. How hard,even if you know very little about testing or are new to automated testing, do you think it is to test the method above? 5 minutes? 10 minutes? An hour? Compare any of those estimates for putting an automated test in place versus the money lost in the first scenario or the time spent in second scenario.
Too often people look at testing for only the non-trivial functions, for example their custom implementation of the Great-circle distance algorithm. It's easy to discount testing the simple stuff. However, a simple bug like this making it's way to production validates the point Steve McConnell makes in Code Complete; the later a bug is found the more it costs to fix it.
If you aren't testing your code, start. Don't worry about whether or not you're doing it right or not if you're new to testing. Any test is better than none, despite what many in the business will tell you. I'd take 10 badly written "unit tests" (that zealots are quick to point out are really integration tests) rather than one well-written one. Testing isn't an all or nothing proposition. It's about ensuring correctness. It's about continuous improvement, being better than you were yesterday. Testing a bit more than you were yesterday. Go on, take that first step, write a test or two.
09-30-2008 9:40 PM