this.Reflect(); - Donn's Weblog : TDD

Intro to Microsoft Unity - Dependency Injection Container

donnfelker — Mon, 26 May 2008 03:40:42 GMT

Note: A full solution is supplied at the bottom of this post if you would like to download it and run it.

A couple of days ago Matt wrote about the new Unity Application Block. The Unity MSDN article describes Unity as:

The Unity Application Block (Unity) is a lightweight, extensible dependency injection container. It facilitates building loosely coupled applications and provides developers with the following advantages:

Simplified object creation, especially for hierarchical object structures and dependencies

Abstraction of requirements; this allows developers to specify dependencies at run time or in configuration and simplify management of crosscutting concerns

Increased flexibility by deferring component configuration to the container

Service location capability; this allows clients to store or cache the container

Designing a software system architecture with loosely coupled components makes life easier in the long run. A few of the benefits of loose coupling are : maximizing testability, modularizing components, and increase the maintainability of the code.

This is a simple introduction into Unity that exemplifies the simplicity of the container setup. I will cover two options for type registration:

Manual Method based type Registration
Configuration file (XML Based) type Registration

The Example Application

The application that is included at the bottom of this post is visualized via the class diagram below. This simple application utilizes very simple implementations of the repository, mapper, domain model, data transfer object (DTO) and service layer patterns for example purposes.

The application follows a very simple flow as shown below:

The console application calls into the Service layer which calls into the repository to get the data which calls into the DB. A domain object is created from the Repository call, which is passed up to the service layer. The Service layer returns a DTO via the DTO Mapper to the parent caller (the console app) and then the console app displays the customer name via a write line call.

None of these layers have any inter-dependent dependencies coded inside of them. I'm using constructor injection to inject dependencies into the calling object.

Once unity is set up, it will find the dependencies and supply them to the program at runtime. Therefore, if I need a ICustomerRepository for the service layer to work properly, Unity will give the Service layer a CustomerRepository instance. Since CustomerRepository inherits from ICustomerRepository Unity is able to make this link (once you've set it up) and supply the proper instance.

Class Diagram

The Setup & Code

The easiest way to see HOW Unity works is to get into the code. My recommendation is to download the sample below, fire it up in Visual Studio and set some break points to see how the code is interacting. Seeing is believing!

Before Unity can supply your application types at runtime, you have to tell Unity WHAT you want it to supply and where to find it. This can be done multiple ways as described here. Today we will go over manual configuration inside of the console app, and xml configuration.

Manual Configuration

The manual configuration that I've utilized here utilizes the fluent interface of the container.

Explanation of code: Here we are telling Unity to register a type. We're saying "If someone requests ICustomerRepository, give them an instance of CustomerRepository. If someone requests ICustomerDTOMapper, then give them an instance of CustomerDTOMapper. ..." and so on.

Using the Container From Manual Configuration

After you've set up the types of objects the container should resolve, you can then ask the container for a instance of "ICustomerService" and then invoke a method call on it. At this very point in time Unity will give you the CustomerService, and then when the customer service needs a repository Unity will then give it a instance of CustomerRepository, etc. At this point in time, everything is mapped for you behind the scenes. The only thing you have to do is ask for the first object and Unity will walk the dependency graph and fill in the blanks for you (if as long as you've given Unity the proper types it needs).

Here's how to do this in the code:

XML Configuration

XML configuration utilizes an external XML file (app.config/web.config) to create its dependency graph. This allows for a lot more freedom in what you would like to do with your app. If you're not happy with a certain version of "ICustomerRepository" you can create a new one, drop the DLL in the bin folder and change this config file to point to the new one and you're done. No recompiling!

In this implementation I'm using the app.config file because this is a Console App for example purposes. The full schema for XML configuration can be found here on the MSDN.

To utilize the XML configuration you'll need to utilize a custom config section. You can do this by placing this code into your config section of your app.config file:

Next, you'll need to add the container and type definition as shown below (this is just a snippet, full code is included at the bottom of the post):

The container gets its types from the config file at runtime.

Each type is declared in the config file as the "type" of object to find and the "mapTo" defines which object to return when the "type" is requested.

The type definitions are declared as type, assembly.

Using the Container From XML Configuration

To force Unity to use the XML Configuration you have to perform few extra set up steps in the application code as shown below. Essentially you're telling Unity that it's configuration/mappings are stored in a config file. The config section configures the container for you, as shown below.

To have Unity resolve an instance, its the same as the manual configuration option above. Here is the same image from above that displays how to do this:

Conclusion

Overall, using Unity as quite simple for this example. The docs on MSDN were pretty good, however I didn't really like the examples that were contained with the download because they did not show you how to utilize XML configuration as I wanted to. It didn't take but a few minutes to figure out what I needed to do. I think Unity is a decent solution at this time. I plan to investigate further into the depths of Unity to see if it may possibly be an alternative for my favorite container tool, Windsor Container.

Download The Code For This Post

FooTheory.UnityExample.zip (~477K)

TIP: Utilizing Fluent Syntax with the "Is" Keyword in Rhino Mocks and NUnit

donnfelker — Fri, 23 May 2008 18:13:58 GMT

Rhino Mocks and NUnit both have a "Is" keyword, both used for a fluent style of syntax. Unfortunately this causes testing problems when you need to use them together. The .NET compiler can only understand one "Is" keyword at a time. We can't use both unless we full qualify the second one.

Having said that, I've fully qualified the "Is" keyword for Rhino Mocks and NUnit before and I find it clunky and I feel its a code smell to me.

In the figure below an example of a fully qualified "Is" keyword for Rhino Mocks is declared.

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 BD5B5E6:8704bd3e-170d-4e31-8c9b-bb81036745f1" style="padding-right:0px;display:inline;padding-left:0px;float:none;padding-bottom:0px;margin:0px;padding-top:0px;">

 1 [Test] style="color:#0000FF;">public void ExampleTest() { // ... items ommited for brevity style="color:#000000;"> With.Mocks(mockery) .Expecting(delegate { Expect.Call(databaseMock.GetStoredProcCommand(null)) .IgnoreArguments() .Constraints(Rhino.Mocks.Constraints.Is.NotNull()) .Return(databaseCommandStub); }) .Verify(delegate { IQuery query = ExampleResultQuery.GetInsertResultQueryFrom(someparameter); IDatabaseCommand command = query.PrepareCommandUsing(databaseMock); Assert.That(command, Is.SameAs(databaseCommandStub)); }); }

On line 11, we can see the fully qualified name: Rhino.Mocks.Constraints.Is.NotNull() method called.

This, my friends, is a code smell (IMO).

How To Fix

The NUnit testing framework provides a "Iz" syntax helper that VB.NET developers use because "Is" in VB.NET is a keyword.

Since we're using .NET Managed code we can use the Iz keyword and it will achieve the same results as Is did. Therefore we can use the Is keyword in Rhino Mocks and we can use the Iz keyword in NUnit. This saves a lot of key strokes over the course of a day.

Final Example:

 1 
 2 [Test]
 3 public void ExampleTest()
 4 {
 5     // ... items ommited for brevity
 6     
 7     With.Mocks(mockery)
 8     .Expecting(delegate
 9     {
10        Expect.Call(databaseMock.GetStoredProcCommand(null))
11            .IgnoreArguments()
12            .Constraints(Is.NotNull())
13            .Return(databaseCommandStub); 
14     })
15     .Verify(delegate
16     {
17         IQuery query = ExampleResultQuery.GetInsertResultQueryFrom(someparameter);
18         IDatabaseCommand command = query.PrepareCommandUsing(databaseMock);
19         Assert.That(command, Iz.SameAs(databaseCommandStub)); 
20     }); 
21 }

Please note: Line 12 has the normal "Is.NotNull()" call from Rhino Mocks, and Line 19 utilizes the Iz syntax helper from NUnit.

I find this much easier on the wrist. :)

Beginner Test Driven Development Habits

donnfelker — Sun, 23 Mar 2008 18:28:05 GMT

Having worked on quite a few teams where I've been the lead responsible for helping implement TDD or been an Agile Coach - I've seen a group of habits develop when teams first start utilizing TDD. These are ...

1. No test isolation

All functionality that is being tested is in one test. Tests are heavily over specified.

How to fix: Spend some time pairing with the developers that are having the issue. Help explain why we want to break tests apart into smaller units, aka: "UNIT" tests. Let them know that we do not want to test the entire class in one unit test. Just because it can be done doesn't mean it should be done. Ya know, I COULD drive into oncoming traffic, but its just not a good idea. :)

2. Failure to recognize the TDD Mantra

Most new TDD'rs will go from Red to Green to - I'm done! Nope. I'm sorry guys, we have one more in that list - Refactor. Let's say it together. Red/Green/ReFactor, Red/Green/ReFactor :)

How To Fix: Help the developers realize that we want to refactor for a reason. We have a passing test, we know what to expect from our results. Now lets clean up our code, maybe introduce some interfaces, change some variable names, introduce some fields, extract some methods, etc. Doing this allows us to clean up the code as well as have the confidence that our changes did not muck up the expected result. Run the unit tests after you refactor. If it breaks, oops, lets go figure out WHY it broke. We caught the error early, its a lot cheaper now. :)

3. The previous lends itself to Insufficient Test Coverage/TDD is my new Debugger

The developers usually will do enough to get the test passing and then move onto the next task. They think of TDD as a new debugger.

How To Fix: Sit down with the developers that have this issue and explain: Just because we can now unit test a method/object and step through it with a debugger doesn't mean that this is the new debugger. That's not the point. Just because the test passes doesn't mean we're done. Just because your method passes if you pass a valid object into it doesn't mean that its fully tested. What happens if I pass a null object into it? What happens if I pass a new'd up object with nothing instantiated? Have those instances been tested? Have we tested that our objects are interacting as we expect them to? Do we know if the Logger got called? How do we know if we didn't test it? That its the classic question: How do we know it works, if we don't have a test to prove it?

4. No concept of separation of concerns or IoC/dependency injection.

This is not a big deal and I expect it of most new TDD converts. Usually while learning TDD the first few tests do not need DI/IoC, but this is something that will help in the future and will need to be understood to really grasp. This really comes into play when we start separating our concerns and breaking dependencies between objects. The refactoring that takes place here can really get deep into DI/IoC sometimes.

How To Fix: Give them a great intro into interfaces and how they're used. Show them great articles on DI/IoC written by Martin Fowler, Jeremy D. Miller, Ayende, and have them join certain mailing lists such as altdotnet to join in/read the discussions. On that list alone, DI/IoC discussions occur on a daily basis.

5. TDD Complaints

I've seen complaints such as:

It takes too long to write the tests
I write more test code than real code.
The tests are harder to write than the real code.
How is this going to help me get my project done? I can just hit F5 and test it and I can tell if it works or not with my own eyes.
Who cares if it passes a unit test, I'm the only person who works on this project.

How To Fix: This is one of those habits I've seen in every place I've coached. These are classic examples of someone who hasn't "seen the light" of TDD yet. In my experience, the easiest way to help them see the light is to pair with with them while writing unit tests. They will instantly see why the unit tests help them and the team. Every single time I do this I help the TDD newcomer realize that by writing this test they've exposed X bugs that they didn't think about before. It usually goes like this: "Ok, that test passes, what would happen if an empty string was passed into this? Would the DB accept an empty string?" Them: "Oh... good point, I didn't think of that." Instantly lights start turning on. Another thing that works great to help developers see the light is to ensure that you're utilizing Continuous Integration such as CCNET, or TeamCity. Have them create a unit test for a section of code. Check it in. Watch it build and watch unit tests pass. . Then have them change the code (the code which is under test) and ensure it returns a different result. Maybe it returned a user's name, such as "bob", now have it return the users name with some characters appended to the end of it, such as "bob123". Have them check it in, watch the build fail because the unit test failed. Explaining to them that this helps catch errors before the product is live is crucial. Once they have the "Ohhh!! I get it now moment", they won't want to stop writing tests.

Gleaning Clarity Through Unit Test Names

donnfelker — Fri, 08 Feb 2008 04:56:19 GMT

You're unit testing, right? .... right? (If not... shame on you... ) It's known that TDD/nDD types of development dramatically increase the ability to refactor with confidence, increase code readability and help define and enforce business rules (in the tests). Unit testing helps with TONS of things in development (literally the list could go on and on), but what about the unit test names? What do those do for us as developers?

Predecessors In The Name Game

Roy Osherove has a good post on Unit Test names. Jean-Paul also has tons of good info about unit test names on his blog. I tend to follow these same guidelines. Also - awhile back on the altnet list there was a thread which spawned this post, but unfortunately I could not find it. If I do run across the post I'll augment this thread with the link.

Background

But what about when a bug report comes in? In my work I've used an alternative method so I thought I'd post it here.

Lets say the bug report says that "CalculatePayment" is returning the wrong value when the system is in a certain state. This kind of test was completely missed during development. Heck, it happens! Your task is to implement a solution for this bug.
Most likely you're going to write a unit test to assert that the solution you specified has been implemented as expected.

Naming Convention

When naming these unit tests I will add the word FIX_<WorkItemNumber>_<MethodName>_<StateUnderTest>_<ExpectedBehavior>() as the method name.

Example:

FIX_186_CalculatePayment_WhenRateLessThan1000_ThrowPaymentException()
{ ... }

From this test fixture name I can glean that this is a fix for bug 186, for the CalculatePayment method, for the state when a rate is less than 1000, the method should throw an exception. I've now documented my code as well as created a very readable and understandable unit test name.

I know this is not something everyone wants to do or would do, but in certain companies I've worked at this has helped with work item issue resolution and tracking.