$$SWYNK$$
Why Unit Test?
Unit testing is tests written by developers, not QA. The purpose of unit testing is to confirm that the code works, and fulfills the business rules. In an Agile Software Development Lifecycle, unit tests also function as requiurements documentation..
Unit tests also document how to use the code. If you need to know how a certain method may be used, simply open a unit test exercising that method and you have a working example.
Another benefit of Unit testing is the confidence it provides when changing code. When a requirement is changed or added, simply exercise all the existing unit tests, and you have confidence, if they all pass, that you haven’t broken something already in place.
I have used unit tests for estimating time to modify existing code. The trick is to make the modification in a simple form, and see how many existing tests break. At that point, you know the impact of your modifications to the existing code base. You know are able to estimate what it will take to keep the existing code working correctly.
Personally, I prefer to run all unit tests for a software package, and confirm all pass, prior to checking the code in. I have worked with large code bases where tens of thousands of unit tests may be exercised in a minute or less.
I worked on three stored procedures that had enough complication that it took 40 hours to write test code, and only 10 hours to implement the code. While this may sound like a waste of time, I have written similar kinds of code in the past, and had a lot more time going back and forth with QA, validating that the software worked as required. It is often more time consuming to test set based software because you don’t have access to formulas happening on a row by row basis.
There are a few techniques for unit testing code. Most of them roll up into three:
- Test After Development (TAD)
- Test First Development (TFD)
- Test Driven Development (TDD)
I’ll be digging into these in the future newsletters.
Reader Comments:
Jay:
I’ve resisted it violently, although I couldn’t tell you precisely why. Must be I’ve allowed myself to become prejudiced—my prior FoxPro zealotry demonstrates a weakness on my part for that sort of thing I suppose. It always sounded like writing twice the code for half the result.
Nevertheless, I’ve always been curious. I think your mere mention of it here has tipped me over the edge. I must’ve been pretty close; it seems you’ve finished me off.
I’m going to have a look.
Aaron K:
I was exposed to unit testing when working on my computer science degree. At my job I don’t do software development, but work with SQL Server, Reporting Service and Analysis Services. As we started building up some of our cubes, I wanted to know that the cubes were being structured to accurately report the data. To do this I put together a Reporting Services report that runs SQL query tests and queries against the cube in questions. With conditional formatting in the report I can easily verify that the cube is generating the numbers it should. Now if I could just have this same confidence for SQL queries…
Aaron M:
As a TSQL developer that absolutely loves Unit Testing database code, I fully agree with thoughts on the benefits of unit testing. One of the managers I was working for introduced me to the concept of TDD and wanted to pursue it for our database code we were going to be writing for a new application. It took some time to get used to this new way of developing code, however once we worked through the process and developed a repeatable method for testing our code, the quality and design turned out to be more flexible and verifiable.
The benefits I’ve experienced as a result of unit testing are numerous;
- Smaller SQL objects
- Flexible and verifiable designs
- Suite of repeatable Regression Tests
- Living documentation of your code base
- Developer focus on solving a discrete problem
- Very short feedback loops for the developer
This is a topic I love to discuss, glad you brought it up!
Ian – Re Virtual Machines:
A number of our customers have VM installs of our software. In the majority they use that excellent product from Microsoft call SQL Express. There is a huge advantage (if it works) of having a number of VMs with isolated small applications. The major problem which we have experienced is that a physical machine will run a 4-5 GB SQL Express 2008 database over 5 times more quickly than a VM machine. We have approached VM ware on behalf of our customers and have got zero response and support.
I’m sure this will be a lively discussion. It’s one of those things that is hard to quantify the value rationally. IMHO, as your software base grows, the value of unit tests also grow exponentially. Nothing frustrates me more than a complicated piece of code that nobody is allowed to modify, because it is too fragile. Unit testing makes those kinds of statements disappear.
Share your thoughts or experiences with unit testing by sending me an email at btaylor@sswug.org.
Cheers,
Ben
Featured Article(s)
Product Review: Red Gate SQL Source Control
Red Gate’s SQL Source Control is intended to connect your SQL Server objects to your source control repository. This article reviews installation, usage, support, suggestions and future.