Although I have no concrete numbers, there are numerous software development projects that are well intentioned when it comes to unit testing; however their actual implementation of unit testing falls woefully short of what is considered proper / correct unit testing.
Many times it is because of time constraints and is more of a case of ticking a task as done, when in actual fact what has happened is that legacy code has made it prohibitively time consuming to do correct unit testing. For the most part, teams are doing light integration testing by using existing components to test the class that they are supposedly writing the unit test for. Other times it may be the lack of understanding of what Unit Testing really implies. Quite often the developer will write the unit test with the intention of only testing the class that they are interested in, but have not thought about the way in which the class needs to be isolated in order to perform the testing. The most common culprit causing teams to fall short of correct unit testing are classes that are dependant on database connectivity. I have seen so many cases where the design of the class has been left untouched with the belief that because the tests are concentrated on the class, then it is considered unit testing. In most of the cases I have seen, Unit Testing has been an activity that is planned for towards the end of the implementation and therefore is the activity that receives the least amount of attention (if at all).
Well sadly, despite those best efforts and intentions, it is not proper unit testing. At the end of the day, it turns out that the class in question is not the only unit being tested; quite often it is also the data access layer that comes under test as well.
I think we have all fallen in to this trap, I myself have been guilty of it and I doubt very much there isn’t a single individual that hasn’t fallen in to this “lie” at one time or another. A unit test needs to be just that; testing one unit of code. The code paths that you are testing must reach down to the boundaries of the next class or resource, without actually traversing into that class or resource. I am sure that those of us who have been down this route will being nodding their heads (guiltily) and asking themselves the same question that I did “How can you test a class without data?”
This is true; you do need data for your tests. But it needs to be controlled data, data that the test generates and you know exactly what the outcome of that test is going to be. Thinking about it now, I was very fortunate in my early career to have the opportunity to work for a company that produces both software AND hardware upon which the software was to operate. In the same building we had software and hardware engineers, it was the first time I had the opportunity to see for myself a real test bed and test harnesses – and I’m not talking about the software type either, I am talking about true, honest to goodness test harnesses. The machine testing the PCB (printed circuit board) actually had probes that poked down onto the board and “injected” signals onto the circuits at key points to test the appropriate reaction of the circuits under test. Although this analogy does not truly reflect unit testing as there were points in the circuit that would have meant actually testing the signal across one or two other components, it serves as a useful point of reflection.
The data needs to be injected into the class and should only affect the class under test. Otherwise, how can you tell that the failure of the test is not actually related to an underlying component or some issue with database connectivity? For those of us working in the object driven development environment, we have had the answer staring us in the face all the time. Dependency Injection!
It might sound like a buzzword, but DI has been around for some time. It is based on the use of Interfaces. Yup, that’s what I said – Interfaces. Although the excessive use of interfaces can make it very difficult to know exactly what is the real object that is being passed in to a class, the truth is, as the class under test – do you really care? The answer is No not really. Remind yourself what Interfaces are intended for. They are, in effect, contracts between two (or more) instances. They are an agreement between the parties that x will provide y with data or an action upon data.
If you think of your OO design through the use of Interfaces rather than concrete instantiation of types from directly within your component classes, then you are on your way to using the DI pattern.
Update (April-07-2009): I had previously quoted an article from Wikipedia, which in hindsite was not how I wanted to present DI. Although the article provides a definition of DI, it does so by basing it on Inversion of Control (to achieve Inversion of Control you need to use Dependency Injection). As Martin Fowler states in his article on Inversion of Control, IoC is the container or framework that is made possible by DI. I will cover IoC and it’s practical uses ata later date, but for now I want to concentrate on DI.
By defining the interaction between your classes in terms of interfaces rather than through the use of strongly typed classes then you are immediately starting to de-couple those classes. The idea is simple. By removing the dependency on a concrete Class and shifting it to an Interface, you are in effect, facilitating the implementation of true unit tests.
Thinking about the unit tests you have written previously, I am sure that the majority of us will agree that it has always been necessary to include the use of another class, another instance to actually be able to perform tests on the unit in question. Go on, you’re amongst friends, no-one will laugh. Whisper it out loud if you want to. We could ask ourselves the following questions to see if what we have written are real honest to goodness unit tests or just very light weight integration tests:
- Does the unit require an instance of any other complex class in order to be able to test it? (By complex class I am referring to a class that will cause the code path from your unit test to perform an type CRUD operation on the data received from/petitioned by your component)
- If it is included in a build system, does the build system have to have any special configuration / installation to be able to run the unit test?
- Does there need to be connectivity to a database/network prepared for the unit test to run?
I am sure as time goes by I will add more to this list, but for now you get the general idea. If you have answered yes to any of those questions, then it is NOT a unit test. What we have here then, is integration testing. The code path has not been contained within the unit and therefore we have inadvertently involved one or more classes. The results of the test are then questionable as they do not reflect the actions performed solely within the unit under test.
In the next article I would like to take an example of a legacy laden class and show how we can apply some DI principles to it so that we prepare it for true unit testing.
