Making Software that Doesn’t Suck – With Automated Testing

I’ve seen a lot of different attitudes towards automated testing over the years.   They range from zealous acceptance to complete rejection.  I would like to cut through the rhetoric, pre-conceptions, and mis-conceptions, and start the conversation from the only place that makes sense.

First, a couple of definitions:

Unit Tests – Low level tests for application logic.  Inputs will be mocked or stubbed.  These do not make calls to services or external databases.  They must run quickly, easily, and frequently. Example: testing a method that calculates taxes based on a matrix of product types and zip codes.

Integration Tests – Application logic tests that may make calls to external services or databases.  These are slower and may run less frequently. Example: testing payment submission such that a payment gateway is called, a successful response is received, and that the response is logged to the database.

Functional Tests – Tests that run from a user perspective.  Usually this will mean invoking a user interface and testing that it reacts appropriately.  Example: testing that the user can login, place an order, and receive a confirmation email.  These tests are not the focus of this article

The Business Case: How Does Building Unit Tests Help Me Make Money?

Make no mistake: there are costs associated with building tests, and may require a large upfront investment before any benefit is realized.  In fact, to the non-technical manager, this combination of fuzzy benefits and clear costs may make testing seem like a poor investment.  That line of thinking is at best short-sighted, and at worst, blatantly negligent to your product’s future costs.

Testing helps your product development cycle move faster

This may be counter-intuitive. As it turns out,  a the whole team has much higher confidence that the new features have not broken existing features when those existing features are continuously and automatically tested.  The result is a QA cycle with less defects, which finishes faster and gets the product to market quicker.  The business gains more confidence in product quality during each product development cycle.  The tech team also gains confidence – unafraid to jump in and modify critical parts of the system to meet the latest business need.  The tests got yo back.

Tests provide historical proof about how the application is supposed to function

One client I had actually opposed maintaining a unit test suite for their enterprise system.  When it came time to make some minor enhancements to the billing system it turned into a big project.  The billing logic had become un-maintainable spaghetti from years of monkey patching by developers who had come and gone over the years.  In some cases the business people couldn’t even tell us how it was supposed to work.  We were literally afraid to modify it.  We limped through the project, but started planning a rewrite of the building system as a future project, involving not just the tech team but also business resources to properly document the functionality.


We test because we care about our customers and because we care about our software.



If you’ve read this far, check out my latest project: FindMyBeer , where you can find who sells or serves craft beer near you.