This past weekend I presented the topic "Intro to Dependency Injection and Inversion of Control" at the Phoenix Desert Code Camp. A big thank you goes out to everyone who attended. It was such a popular topic that it actually moved up to the largest room in the conference location, the Theater at UAT! Thanks again everyone!

At the bottom of this post are the resources from this presentation.

Resolution from Error During the Presentation

For those of you were present when I ran into an issue with this "DynamicMethod" error, I have figured out the issue. It's a bug in Unity. It looks like its been fixed and should be available in the next release.

I was able to work around this issue by moving the Dependency attribute into the Interface. I have updated the code in the download below to reflect this.

Presentation Resource Download

Full Solution Download (900K)

PowerPoint Presentation

You can also view the presentation online - located here.

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:

1. Manual Method based type Registration
2. 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)

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.

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

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. :)

Normally unit testing is used to verify that state is being altered as expected and interactions are occurring as expected (state based testing or interaction based testing). We also write integration/functional tests to ensure that layers and components are working together correctly in the overall picture.

While in the field I've noticed that most tests neglect the attributes of the WCF ServiceContract. Shouldn’t these be tested as well? Yes, they definitely should!

You may say .... "OperationContractAttribute  is just an attribute that indicates that this method is part of a service contract in a WCF application, so why do I need to test the attribute?" 

Good question... consider this scenario:

You're the developer on a large enterprise system and you've created a WCF Service that handles processing sets of data. Depending on the parameters, this data can take hours process. Therefore you've decided to implement the "IsOneWay" attribute value on the OperationContractAttribute.

Is One Way explanation:

Use the IsOneWay property to indicate that an operation does not return a reply message.
...
If the IsOneWay property is set to false (the default), even methods that return void result in a reply message. In this case, the infrastructure creates and sends an empty message to indicate to the caller that the method has returned. (Using this approach enables the infrastructure to send SOAP faults back to the client.) Setting IsOneWay to true is the only way to cancel the creation and dispatch of a response message.

Why Testing IsOneWay Matters

Now that you've set the IsOneWay value to true in your service, the calling applications can fire off a request and let the service crunch away on the request (remember, in this scenario, it may take hours to complete). This is an expected behavior of your service - having the method return as soon as its sent without waiting for a response message from the service.

Fast forward 4 weeks .... Joe Developer decides to remove the "IsOneWay" value (which in turn changes it to false, which is its default) because its not working for his new application as he expects. Everything works for him now, and he checks in the code to source control. Everything builds on your continuous integration environment. All tests pass, everything looks golden.

The new service updates and application updates get applied to production and almost immediately users start complaining about another line of business application "freezing up" when they click a certain button.

"All of a sudden, when I clicked the <Load Data> button, the application just froze. I just left for lunch and when I came back everything was normal. Now, its doing it again. I'm not sure what's going on. This application sucks."

You check the app logs, event viewers, traces, etc and then realize that the application IS WORKING but it stops for quite awhile at the service call. The weird thing is that the code does not throw any errors, it just takes forever to return from that call. This problem seems to be a performance problem. If you're not careful this problem could masquerade itself as another probelm in your mind:

"Is the network slow?"

"Is the service down?"

"Is it doing a retry?"

"Are all the packets getting transmitted?"

The list could go on and on.

The Reason For the Slow Down in the App

Why is the app performing so poorly at this service call? Because IsOneWay was set to false (default when not preset in the attribute values). The app that was written 4 weeks ago expects IsOneWay set to true so it does not block the current thread waiting for a response from the service call.

Since the call is set the value of IsOneWay is set to false, the application is now hanging.

How To Prevent This

The continuous integration environment should have had a test for this. Either unit test or integration test. Unfortunately it did not, and in most companies I don't see a test for this kind of thing, ever.

To fix this we need to implement a unit test for this attribute. We need to make sure that it is set to TRUE so that we dont break anything.

Code

Below is the code to implement the test for the IsOneWay attribute value.

FooTheory.WcfServiceExample.cs  - The service we need to test.

 1 using System.ServiceModel;
 2 
 3 namespace FooTheory.WcfServiceExample
 4 {
 5     [ServiceContract]
 6     public interface IFooTheoryWcf
 7     {
 8         [OperationContract(IsOneWay = true)]
 9         void Execute();
10 
11     }
12 }

The Unit Test

FooTheoryWcfContractTests.cs

 1 using System;
 2 using System.ServiceModel;
 3 using FooTheory.WcfServiceExample;
 4 using NUnit.Framework;
 5 using NUnit.Framework.SyntaxHelpers;
 6 
 7 namespace FooTheory.WcfExampleTests
 8 {
 9     [TestFixture]
10     public class FooTheoryWcfContractTests
11     {
12         private readonly string ONE_WAY_METHOD_NAME = "Execute";
13 
14         [Test]
15         public void Execute_Should_Be_OneWay()
16         {
17             object[] atts = typeof (IFooTheoryWcf)
18                 .GetMethod(ONE_WAY_METHOD_NAME)
19                 .GetCustomAttributes(false);
20 
21             OperationContractAttribute opAttribute =
22                 (OperationContractAttribute) Array.Find(atts, 
23                 delegate(object obj)
24                   {
25                       if (obj is OperationContractAttribute)
26                           return true;
27                       return false;
28                   });
29 
30             Assert.That(opAttribute, Is.Not.Null, 
31                 "Could not find the attribute connected to the method that is needed.");
32             Assert.That(opAttribute.IsOneWay, Is.True, 
33                 "Method should be marked as IsOneWay for Application X");
34         }
35     }
36 }

Code Explanation

The unit test uses reflection to get the attribute of OperationContract and then it checks to see if its not null and also checks to see value of the IsOneWay property.

Conclusion

If either one of these asserts fail, the build will break in the continuous integration environment. This will let the dev's know that something they did broke an expectation on the service contract. Catching this type of problem early in the cycle can help immensely. Not only does it save time, but it saves money in both dev time as well as end user time.

If you don't catch this early on, you could be calculating the costs of lost time of a couple of devs as well as numerous end users who are using the dependent application(s). If you're using this Service in a SaaS approach, you could really been in some hot water with those clients that utilizing your service. No one wants to use a service that is unreliable.

So, remember, test early and test often! Get those WCF Attributes under test!

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:

1. It takes too long to write the tests
2. I write more test code than real code.
3. The tests are harder to write than the real code.
4. 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.
5. 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.

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.

I'm not going to lie, I'm a NUnit guy. I've used it for years. But just recently I've decided to start using MSTest. I run Team Suite and I've been using it for some basic integration and functional tests, but not full on TDD. Well this weekend I embarked on a task that utilizes full on TDD and I decided to make the jump and try to do it with MS Test.

So the first thing I had to do was reference and import Rhino Mocks. I then ran the test real quick (I had a test that did not depend on mocks yet) to make sure nothing in the import broke it (it shouldn't, but hey, I'm ADD when it comes to this TDD business). To my utter amazement, something broke. I was seeing red.

This was the beautiful error:

Microsoft.VisualStudio.TestTools.TestManagement.ExecutionException: Test Run deployment issue: The location of the file or directory '(path omitted)\main\Source\SharedBinaries\Rhino.Mocks.dll' is not trusted.

WTF? It's on my local machine. It's not a file share, hell, its even included in my project in my SharedBinaries folder. WTF MAN!?

After some looking around, I was able to figure it out.

If you download a DLL from the Internet, or get it in an email or where ever and you saved it to your disk (including a DLL in a zip too) it has some extra info attached to it called an "AES" file. (see my reference below for more info)...

To fix this annoying issue, go to the DLL, right click and then click "Unblock". See the screen shot below. Once that is done, your test will work.

Source: MSDN Forums

That's right. Read it again.

"A Sandbox Server Is a Sandbox For A Reason." Now, read it again, and again, and again. MEMORIZE IT.

What is a Test/Sandbox Environment?

A test/sandbox environment is a testing playground for the developer/user (in the context of this conversation, its developer). Its an exact copy of the production environment, but does not affect anything in production. It allows the developer to test code before it goes into production. This allows the developer to find errors before they actually cost the company any money. Test/Sandbox environments are an integral part of software development and service providers. They make sure that the quality of the product released is top notch (of course this is assuming proper testing is taking place).

This is nothing new, its not rocket science. Everyone tests before they ship a product (well, anyone with a brain does at least).

When you're working with a service provider you expect them to have a test/sandbox environment that matches there production environment. Tons of service providers have these test servers, here's a few:

• Google AdWords Preview Tool - Lets you preview searches using Google so you can preview your ad before it goes live.
  • Benefit - You don't get penalized for impressions or clicks. No money is spend, no money is transferred.
• Google Checkout Test Server - Allows you to post test transactions.
  • Benefits: You can test without being charged or have actual money transferred.
• PayPal SandBox - Lets you test your Pay Pal transactions.
  • Benefits - You can test without being charged or have actual money transferred.
• Amazon Mechanical Turk SandBox - Allows the users to test their applications and HITS.
  • Benefits - You don't loose money nor put up a HIT that could be worked on. (You pay for HITS). No money is transferred.
• Amazon Flexible Payments Service (FPS) - Allows you to test the payment systems you set up.
  • Benefit - Money is not actually transferred.
• SalesForce Sandbox - Allows developers to post test transactions to the Salesforce Service.
  • Benefits - Eliminates costly development mistakes. Helps save on testing, therefore eliminating money being transferred for a development task.
• Virtual Machines (Virtual PC, VMWare) - The big daddy of them all. Test your entire environment before you put it into production.
  • Benefits - Eliminate HUGE costs associated with lack of testing/deployment scenarios.

These sandbox environments share a common goal - THE GOAL OF ELIMINATING COSTLY MISTAKES

How? Simple. If developers are given a test environment, they can test their code without worrying about messing up production environments. If these services involve money, its VERY IMPORTANT that the said service has a test environment.

A real life story...

Recently I was working on a side project that involved a service provider (none of the listed above) and I found their test server to be quite useful. I could post transactions to it, and do all the testing I needed to. A few weeks later the production site changed, yet the test server remained the same. Not only is this irresponsible as a service provider, its a risk that the service provider puts on themselves. They have now put themselves in a position where the service might now work, and some users might abandon the product. Upon asking the service provider when the test environment would be updated to mimic the production environment I got this response (edited to make sense in this context):

"There's really no point in having an exact copy of production since it's only really designed for practicing entering form data. Our live environment changes daily (along with other criteria) and, other than changes to form validation or form fields, these changes are never reflected in the test environment (which is also why there are some different types in the test environment that don't exist in the live environment)."

Huh? What!?! Lets go over a snippet of this... the first part really makes my jaw drop.

"There's really no point in having an exact copy of production since it's only really designed for practicing entering form data."

Whoa, DANGER, WRONG WAY, TURN BACK, for real... for real. Ok, well, the last time I checked when you have a test environment - its a test/sandbox environment for a reason: It mimics the production environment to allow the developer to perform tests without affecting anything in production. So why is there no point? If its not the exact same thing, then how am I to be sure its going to work the same. That's right, I WONT KNOW.

Unfortunately this service provider has not updated their test server to this day. It's a service that I need to use, but I will openly admit, I think its a bad business decision on their end. I've had to perform all kinds of trickery to validate my code does what is supposed to do, but still, I'm only 65% sure its right. Which sucks, no test server, no way to test everything.

This is a lesson that all service providers and developers should note...

A broken test environment is like having no test environment at all.

Just imagine, if you can't compile your code, you can't ship your code. So, if you cant test your code properly, how can you be sure its doing the right thing? You cant.

Service providers: Make sure you  have a valid test environment that mimics production, EXACTLY.

Developers: Demand a test environment. Ruthlessly test your code. Unit test to hell. Functional test your code like hell.

Jeremy D. Miller has a great post on keeping source code where it belongs. The thought process behind this is that code should be where YOU would assume it would be. If its data access code, it should be in a project/namespace that is something like Data Access or DAL or Data or something that represents the lower layer of the architecture. If its the business rules/tasks the files should be in a project called Business Rules, or BLL, or Tasks, or something similar. It makes sense, just think about this -- if you walk into a business and are given a project that was created by another developer and you're getting a ADO.NET Exception, you'd expect to find the code Data Access code in a Data Access layer, NOT in the code behind. I should not have to hunt down where you put your data access code.

We're talking about basic separation of concerns. The thing is, many developers lack these concepts because they're under the assumption of "I can write this the correct way, and it will take me 2 weeks, or I can do it quickly and it will take me 2 days." This may not matter when the application is running for a few months, but when you are asked to change the data provider from SQL Server to Oracle, or remove the web service calls and replace them with RPC calls, you're going to find yourself in a world of hurt because you didn't set everything up correctly. At this point they have amounted a large amount of Technical Debt.

He also noted that a large number of people were now using Ruby On Rails (RoR) as their development platform and I won't deny that I also believe that Ruby/Rails is huge right now. Tons of shops are running RoR and even Martin Fowler said on Hansel Minutes that ThoughtWorks was doing about 40% (or more) of their business with Ruby. The key point Jeremy brought up is that "RoR forces web developers into a bit of a straight jacket, but that's a good thing in a way." I completely agree. RoR enforces a consistent source code tree layout which allows for developers to easily find there way around a project. "Developer A" can create a project with RoR and then "Developer B" can come along and take a look at it and be familiar with the code layout and structure. The RoR community has agreed that this is the basic way to organize a project and it seems to be working for them.

So what about .NET? Enter Tree Surgeon. Right now, its a stand alone application, but in its near future it should be implemented as a template in Visual Studio 2005/2008. So what is it? It's a application that will create that straight jacket that Jeremy spoke of. It gives the developer a basic set up of layers, unit tests, code coverage and build script. It builds the entire source code directory and allows you to build on top of it. The source code layout follows a white paper written by Mike Roberts. I've been using it for quite awhile and I'm one of the developers on the project. I recently updated the source to allow creation of Visual Studio 2005 projects. Please note, this is only on the source and has not been reflected on the production release. Download the source, run it and then choose a application name, and generate the project source directory tree. Open the solution file and your application is ready to go.

The best part is that its easy to integrate existing projects into this format. I've done it quite a few times to allow for easy integration into my clients CI environment.

If you have any requests for Tree Surgeon, please visit the Issue Tracker page and submit and issue.

Enjoy!

Recently my company decided it was time to automate some of the plumbing work, such as the data access layer (thankfully). I checked out a few options (LLBLGen, MyGeneration, CodeSmith and SubSonic) and finally decided on CodeSmith because I had used it before and I felt it was the best fit for the company (in many different areas).

I'm using .NetTiers to create the plumbing code for our applications.

In .NetTiers, Processors are used to add custom business logic into the processing of your data. For example, perhaps you want to make sure that a country only exists ONCE in your system, you could add this functionality here. This thread covers the topic of how to add a a processor to your service layer.

The only problem is that if you want to test your processor using Unit Testing, you are now also testing the data access, database, etc. Its tightly coupled, there's not an easy way to test this. But in actually, there is. Here's how:

The problem lies in the ValidateIfCountry method. It has a dependency on the "CountryService". We cannot mock this out. Its tightly coupled with the Processor. We can eliminate this coupling by injecting a reference to a "CountryService" through constuctor injection. Here's how. (please refer to this thread for full doc on this class).

Previous Constructor Code (with private members shown):

private Entities.Country _country;

/// <summary>
/// Country Processor
/// </summary>
/// <param name="country"></param>
public VerifyCountryProcessor(Entities.Country country)
{
   this._country = country;
}

New Constructor Code, injecting a CountryService:

private Entities.Country _country;
private CountryServiceBase _serviceBase;

/// <summary>
/// Country Processor
/// </summary>
/// <param name="country"></param>
public VerifyCountryProcessor(Entities.Country country, CountryServiceBase serviceBase)
{
   this._country = country;
   this._serviceBase = serviceBase;
}

How to Inject it from the original CountryServiceClass

In the example provided by the .NetTiers team, they said to override the Insert Method with this code, to get the processor to run:

Old Code

public override bool Insert(Order entity)
{
   ProcessorList.Add(new VerifyCountryProcessor(entity));
   Execute();
   return base.Insert(entity);
}

This is is correct, but this time we need to inject a CountryService object into the Processor.

New Code

public override bool Insert(Order entity)
{
   ProcessorList.Add(new VerifyCountryProcessor(entity, this));
   Execute();
   return base.Insert(entity);
}

Since we are already in the "CountryService" class when we're overriding the Insert Method, and since the CountryService inherits from "CountryServiceBase", we can inject this reference into the InventoryProcessor through the constuctor. We have now eliminated the tightly coupled reference inside of the processor. We can now test the functionality through unit testing.

How To Test

I utilize Rhino Mocks for my mocking so here's how to do it with Rhino Mocks.

#region Using Directives
using System;
using System.Collections.Generic;
using System.Text;

using ExampleCompany.App.Entities;
using ExampleCompany.App.Services;
using NUnit.Framework;
using Rhino.Mocks;
using ExampleCompany.App.Services.Pipeline;

#endregion

namespace ExampleCompany.App.UnitTests
{
   [TestFixture]
   public class CountryProcessorTest
   {
      #region Test Setup
      MockRepository mocks;
      CountryService countryService;

      [SetUp]
      public void SetUp()
      {
         mocks = new MockRepository();
         countryService = mocks.CreateMock<CountryService>();
      }


      [TearDown]
      public void TearDown()
      {
         mocks.VerifyAll();
      }

      #endregion 

      #region Tests
      [Test]
      public void TestCountryProcessorForDuplicateName()
      {
         Country country = new Country();
         country.Country_Name = "FOO";

         // Needed for a return value
         TList<Country> cs = new TList<Country>();
         cs.Add(country);

         string whereClause = String.Format("{1} = '{0}'", CountryColumn.Country_Name.ToString(), country.Country_Name);

         Expect.Call(countryService.Find(whereClause)).Return(cs);

         Country country2 = new Country();
         country2.Country_Name = "FOO";

         VerifyCountryProcessor countryProcessor = new VerifyCountryProcessor(countryService, country2);

         Expect.Call(countryService.ToString()).Repeat.Any();

         mocks.ReplayAll();

         IProcessorResult result = countryProcessor.Process();

         Assert.AreEqual(false, result.Result);
         Assert.AreEqual("The country FOO already exists and cannot be added or updated.", result.BrokenRulesLists[typeof(ExampleCompany.App.Entities.Country)][0].Description);
      }


      #endregion
   }
}

Conclusion

By utilizing dependency injection in the processors, we're able to successfully test the processor utiliting unit testing without having to worry about a database connection at the same time. Very helpful. :)