Unit Testing

Inversion of Control

Desirea Herrera — Sun, 26 Jul 2009 17:04:32 GMT

While I was reading The Art of Unit Testing by Roy Osherove, I found references to topics that required more investigation. Inversion of Control or IoC was one of them. I vaguely remember reading about it somewhere but being a tech trainer of way too many technologies, and now a lab developer (basically quality assurance checking & screnshotting of MOC labs & labs from other companies), I've let some topics slide away in favor of stuff related to my job. It's part of the reason I started writing this blog, to hone my skillsets. And now, on to Inversion of Control:

Inversion of Control is based on the idea of flow control. When you start programming, you learn to write code in classes and methods that control the flow of the program. Your code calls methods that do something and answer back to your code. In Inversion of Control, your central classes wait for the phone call that tells them things they need to know to perform their own activities.

The example onWikipedia shows a serverFacade class that initially takes an object parameter to its respondToRequest method. The object is a request for data. The respondToRequest method then uses a DAO (Data Access Object) to get data via it's getData method and convert the data via the aspect's convertData method after using the businesslayer object to test if that object is valid. Based on the first implementation, the serverFacade object is coupled to the DAO object. In the lab of OOP, coupling is discourage. Since the serverFacade shouldn't know anything about how to convert data, or what to return if the data conversion fails (it is only a facade after all), the second implementation moves all the data conversion and return decisions to the DAO class. This in effect, decouples the two classes.

In Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, he uses a simple class that splits out finding all movies to a finder class. Problems arise when his friends want that functionality for their programs. They might want to store movies in a different format or in a database. An interface or abstract class solves this by allowing the new developer to create a new class to pass to the MovieLister class that can find all of the movies in their own way via their own implementation.

The key points to both of these examples is that :

The classes need to have very specific goals. If an activity doesn't correspond to the method or class, it needs to be moved out.
In order to allow for different external dependencies like how the movies are stored and retrieved, create an interface or abstract class. (This idea makes your program easier to fit different situations as needed.)

Based on Fowler's explanation, what we're really talking about is setting up "plugins" for our software. Essentially you now have the ability to plugin any external movie storage into his MovieLister class. Data storage is only one of the types of external or outside dependencies your software could come across. It could also rely on network availability, configurations as well as configuration files or data stored on a network, or outside services.

Fowler asserts that Inversion of Control is a common characteristic of a framework. In Inversion of Control he says:

"A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points."

Fowler also thinks Inversion of Control Containers is too generic and renames this to Dependency Injection and further discusses the Server Locator pattern. I highly suggest you read his full article.

Going back to the Wikipedia article, it mentiosn that Inversion of Control is also known as the Hollywood Principle. Basically is the ""Don't call us, we'll call you." concept. IoC takes the integration and configuration of the system out of the application, and performs dependency injection.

Unit Testing Review List

Desirea Herrera — Tue, 07 Jul 2009 17:26:18 GMT

Unit Testing in Visual Studio

Desirea Herrera — Mon, 01 Dec 2008 08:50:39 GMT

The more I learn, the more I know I don't know. As an MCT, it's my job to continually update my skills. To that end, I've been delving into things that aren't covered in the courses I teach. Things like Unit Testing.

What's A Unit Test?

With Visual Studio 2005 and 2008, you get the ability in some versions like Team System to create a Test Project to do Unit Testing. Before I start talking about creating a unit test, let's review the basics. A unit test verifies that a function actually performs it's duties. Now, there are black box and white box types of tests. A black box test only tests that a function accepts only the datatypes it's designed to accept and returns the data or no data that it's expected to return. In other words, you put in certain stuff and get certain stuff back. Now a white box test actually allows you to know what's going on between the input and output. White box testing ensures that you actually are testing all code pathways. It's called "Code Coverage". For more information about Unit Testing you can check the following links:

It's important to write your Unit Tests before you actually develop your application. After identifying the requirements of the application, a unit test can define the functionality of different pieces of the code before it's written. Unit testing helps to maintain the integrity of your code during refactoring. You'll always be able to test that the function still fulfills it's intended purpose.

Generating a Unit Test in Visual Studio

The simplest method of generating a unit test in Visual Studio is to right click the name of any method and select Create Unit Tests. Be aware that not all versions of Visual Studio support Unit Testing. You can also create a new Test Project to add to the project and then, a test class can be added by either selecting from Add New Test popup or by selecting Unit Test from Add menu. This brings up the Create Unit Tests screen where multiple methods to be tested can be selected.

Visual Studio only actually writes a basic stub for the Unit Test. It's up to you to fill in the blanks for the application. You'll do things like test that the return values are the correct datatype and within the expected value range. You'll also check to make sure the funciton only accepts the data it's suppose to accept.

You'll normally see the following assert statement:
Assert.Inconclusive("A method that does not return a value cannot be verified.");

If you ran the Unit Test for the method you're testing right now, You'd see the error message "Assert.Inconclusive failed. A method that does not return a value cannot be verified." Now, if you comment out the Assert.Inconclusive statement, you'll have a test that passes because the unit test method isn't testing for anything. That's not going to help.

You'll have to write some test code with the Assert statement. You'll be supplying the method with specific values and comparing the results with the expected result in an Assert statement.

Unit Test Design is Obviously Important

Obviously, did I say that again? Yup, I did. You've got to think of all possibilities going into the method and all coming out of the method. This takes some prior planning. Now it might seem backwards based on what I've just said about right clicking a method and/or creating a Test Project to add to your application. The key is to think out your Unit Tests ahead of time so that you can implement them easily using Visual Studio.

Additional Resources

Good Luck Unit Testing

I've written an additional Unit Testing Review with more links @ Unit Testing Review List