This is the test suite from a project I am working on and I decided to move the BDD naming convention into the syntax:
(class name) + (method name) = behavioral sentence

This library has 100% code coverage and tests the sad path pretty well, in my opinion.

Click the image to get a bigger view.

What’s your opinion? Is this easy to read to understand intent? Does this document my code for the next developer? Or is it just too much?

Many of the technologies we work with don’t easily lend themselves to unit testing: web pages, stored procedures, 3rd party controls.  You’ll probably have to learn some new technologies that make testing practical, which also takes time and energy.  You might have to write test barriers between the "untestable" part, and the logic; moving as much logic out of the hard to reach area and into easily tested code as possible.  Which at a minimum represents more classes, more complexity, more typing…

Writing testable code is hard, and requires a shift in how you write code.  This shift won’t come overnight.  At first you will write "sort of" testable code, hopefully following some ideas laid out by other codebases (Various parts of Castle, ASP.NET MVC, and Rhino-Commons and other examples by Oren Eini are some good places to start).  You will end up making mistakes, and a few months later you’ll look back at this code and wish you had done things differently.  If you’re not having that experience with your code, then how have you improved as a developer?  If you look at last year’s code and think that you’d change absolutely nothing, doesn’t that at least imply you haven’t improved your skills?

"But, we don’t have time to write unit tests."  Does that mean that you have time to debug your application by stepping through hundreds of lines of code?  Do you have time to litter your code with printf()s hoping to track down where a variable gets set to null?  Maybe we’re just too used to the Edit-Build-Debug Cycle taking minutes for each iteration, waiting for ASP.NET to finish compiling its pages so we can navigate to where the problem is, enter what we think the bad data is, click a button, and then start hitting breakpoints… lather, rinse, repeat, for hours on end.

So when the project gets to the end of the timeline and budget, and the result is buggy, and we’re breaking more things with each deployment because of regression issues, and the client starts saying things like "this project is a total failure," and the project manager is demanding that everyone start putting in all-nighters to deal with the bug list … is that better than an alternative of spending a little bit more time up front on writing easily-tested code? 

So, how about we strike a pragmatic agreement – identify a difficult part of an application you’re working on, and figure out how to write unit tests for it.  I’m not even talking about "test first" or "100% test coverage," just write something to make it easier to confirm that the behavior of this code is correct.  At least identify the parts of your code that stand in the way of tests – its almost always database or web-dependencies, and is an indicator of further problems, but we’re taking baby steps here.  See how that goes, and see what you can learn from it.

I await your flames in the comments…

The sessions I will be presenting are:

• "Healthwise – An Agile Adoption Case Study" – This is a co-presentation with our PMO officer, Ken Long.
• TDD Clinic: .Net and C#

I really hope to see you there (there are great parties).

   1: public class CustomerBuilder

   2: {

   3:     public String _firstName = "Homer";

   4:     public String _lastName = "Simpson";

   5:         

   6:     public CustomerBuilder WithFirstName(String firstName)

   7:     {

   8:         _firstName = firstName;

   9:         return this;    

  10:     }

  11:  

  12:     public CustomerBuilder WithLastName(String lastName)

  13:     {

  14:         _lastName = lastName;

  15:         return this;

  16:     }

  17:         

  18:     public Customer Build()

  19:     {

  20:         return new Customer(_firstName, _lastName);    

  21:     }

  22: }

This fluent builder class can then be used this way:

   1: Customer customer = new CustomerBuilder()

   2:     .WithFirstName("Homer")

   3:     .WithLastName("Simpson")

   4:     .Build();

A while ago, Greg Young started a series of blog posts on DDDD (Distributed Domain-Driven Design), which I can highly recommend. Make sure to catch up now you still can because I think that he has a lot of stuff coming up, which I’m really looking forward to.

Anyhow, Greg had a couple of posts on fluent builders, which you can read here, here and here. I noticed an interesting approach in the way that the target object is built. Here is an example of this approach:

   1: public class CustomerBuilder

   2: {

   3:     public String _firstName = "Homer";

   4:     public String _lastName = "Simpson";

   5:         

   6:     public CustomerBuilder WithFirstName(String firstName)

   7:     {

   8:         _firstName = firstName;

   9:         return this;    

  10:     }

  11:  

  12:     public CustomerBuilder WithLastName(String lastName)

  13:     {

  14:         _lastName = lastName;

  15:         return this;

  16:     }

  17:         

  18:     public Customer Build()

  19:     {

  20:         return new Customer(_firstName, _lastName);    

  21:     }

  22:  

  23:     public static implicit operator Customer(

  24:         CustomerBuilder builder) 

  25:     {  

  26:         return builder.Build()    

  27:     } 

  28: }

which results in the following usage:

   1: Customer customer = new CustomerBuilder()

   2:     .WithFirstName("Homer")

   3:     .WithLastName("Simpson");

Where it led me was to re-investigate Partial Mocks in Rhino Mocks.  My original misunderstanding of Partial Mocks was that they would only mock Abstract Classes.  A partial mock will mock ANY class — but only the Partial mock will only mock abstract methods.  That small misunderstanding has caused me to loose untold amount of hair and good will towards all men.

So I’m going to re-implement my class methods.  Here you go:

public class MyClass
{
    public int Foo()
    {
        // stuff happens here
        int i = Bar();
        // do more stuff here    
        return i + 5;
    }
    public virtual int Bar()
    {
       // do some logic
       return 1;
    }
}

A few changes here.  First, I removed the delegate and renamed BarInternal back to Bar.  Second, I marked the Bar method as virtual. 

They key point about a virtual method is that you can provide an implementation, and then a inherited class can completely override that method.  That is what the Partial Mock is allowing us to do.

So how do I write my tests?  If you don’t like using Rhino Mocks you do this:

[Test]
public void FooTest()
{
    int expected = 7;
    int result = 0;
    MockRepository mock = new MockRepository();
    MyClass c = mock.PartialMock<MyClass>();

    using (mock.Record())
    {
        Expect.Call(c.Bar()).Return(2);
    }
    using (mock.Playback())
    {
        result = c.Foo();
    }

    Assert.AreEqual(expected, result);
}

Obviously, now my test is referencing the Rhino Mocks library.  The variable mock is the Mock Repository.  Now the big change is that I don’t create MyClass directly, but through the Rhino Mocks PartialMock method.

Next, I tell the mock repository to expect a call to c.Bar, and when called return 2.  That is what is happening in the using (mock.Record()) section of the code.  Then, in the mock.Playback section, I call Foo().

One other quick note, if we were to rewrite Foo such that it no longer called Bar this test will fail.  The Expect.Call part tell the mock repository that the method Bar will be called, and if it isn’t there is a problem.  There are ways around that as well, but that is a topic for another day.

Where does that leave us now?  Aside from the odd “virtual” keyword thrown into our production code, this is the code as you would have originally written it, even without TDD.  I don’t like making API changes just to satisfy testing, but I am very OK with this change.

But what about that new kid on the block?  You know, Moq.

I still love Rhino Mocks, but I can’t help but want to play with a new toy.  So here is the same thing, but in Moq:

[Test]
public void Foo_moq_test()
{
    Mock<MyClass> mock = new Mock<MyClass>();
    mock.Expect(x => x.Bar()).Returns(2);

    MyClass c = mock.Object;
    int result = c.Foo();
    Assert.AreEqual(7, result);
}

So as you should be able to see, Moq is a very different animal than RhinoMocks.  There is no Record or Playback (the web site calls those confusing, I disagree, but still), and the Expect happens with a anonymous delegate (in the form of the Lambda Expression “x => x.Bar()” where x is of type MyClass).

The cool part is that you can get the same results with less code using Moq.  That has been the main advantage all along.  My informal testing also reveals that Moq is just a hair faster than Rhino Mocks (but not fast enough to warrant switching frameworks).

The problem

You have two methods (Foo and Bar), and Foo calls method Bar.  It will look like this:

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here    return i + 5}

public int Bar()
{
   // do some logic
   return 1;
}

Now you need to test both methods.  Bar can be easily tested like this (this should work for NUnit and MBUnit tests — assuming both methods exist in a class call MyClass):

[Test]
public void Bar_Test()
{
    MyClass c = new MyClass();
   int result = c.Bar();
   Assert.AreEqual(1, result);
}

Now we test Foo:

[Test]
public void Foo_Test()
{
   MyClass c = new MyClass();
   int result = c.Foo();
   Assert.AreEqual(6, result);
}

Here is where we have an issue.  What if the result of Bar changes?  That will break the test.  So now we have a brittle test.  Any time Bar changes, we have to change all of the Bar tests, but also the Foo tests, so we have added complexity to our tests as well.  Now if Foo (or Bar) was in a separate class, this wouldn’t be an issue, but they are in the same class.  And as much as I like small classes, this seems too trivial to split up (even in the context of an extremely trivial example).

The Solution

What I would like to do is Mock the method Bar.  You can do that with a delegate.

Without really getting into what a delegate is, I will just show the code.  So here are my two methods, with a delegate added in for good measure.

public delegate int BarDelegate();

public BarDelegate Bar;

public MyClass()
{
    Bar = BarInternal;
}

public int Foo()
{
    // stuff happens here
    int i = Bar();
    // do more stuff here    
    return i + 5;
}

public int BarInternal()
{
   // do some logic
   return 1;
}

OK, here is what I did:

1. Renamed Bar to BarInternal
2. BarDelegate delegate
3. Created a variable named Bar to point to the method BarInternal
4. Created a constructor to hook up Bar to BarInternal.

Now all of my code can still use the method Bar just like it was there, but in actuality it is calling BarInternal.  I have now created one layer of indirection to my method Bar so it can now be mocked and tested.

Here is my new test for Foo:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = BarMethodForTest;
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

private int BarMethodForTest()
{
    return 2;
}

So what is new with the test is the BarMethodForTest that is passed to c.Bar and I have coded BarMethodForTest to always return 2.  When I set c.Bar to my new method, BarInternal (the default method) is no longer called.

Actually, if I wanted to I could simplify this further by setting c.Bar with an anonymous delegate like this:

[Test]
public void FooTest()
{
    MyClass c = new MyClass()
    c.Bar = delegate() { return 2; }
    int result = target.Foo();
    Assert.AreEqual(7, result);
}

Stepping Back

OK, take a step back and look at this again with a critical eye.  Have I really solved the problem?   Yes and no.  The real problem was that my methods were too complex to simply test.  Now my methods are simple to test, but the code is complex to read.  All I’ve done is shifted the complexity from one class to the other.  A better solution would to have created another class and further abstracted out the logic.

At the same time, my class is not overly burdened by the change either.  In lieu of a real refactoring, I do consider this a viable solution to the problem.  So by all means do this — but make sure you are out of alternatives first.

How would we deal with adding or modifying some functionality in a Legacy application, while moving forward with some better practices?

In the Beginning…

We have a big lump of Legacy Code, a formless void of hard to manage complexity. We need to modify some functionality in the MyConsumerClass, that DealsWithThings and can DoStuff. Let’s modify MyConsumerClass in a way that allows us to decouple what MyConsumerClass does from the rest of the Legacy Code. This will be the starting point for making this application cleaner.

Build in Layers

The class we’re working on relies on functionality from The Cloud for doing something with text. (Maybe we’re showing the latest sales figures from the corporate SharePoint portal – the specifics aren’t very important…)

We want to be able to modify the behavior of the text provider without needing sweeping changes everywhere else. So how do we separate these pieces?

First, let’s change MyConsumerClass to access the text via an interface instead of creating specific instances directly from the cloud. MyConsumerClass is going to ask “something” for the appropriate concrete instance – instead of making decisions about what that concrete instance should be. This “something” is our Inversion of Control Container, and it will know how to pick the right ITextProvider implementation, create one of them, and return the reference to MyConsumerClass for use.

The type that the IoC returns might be a thin wrapper on top of the “real” functionality in the Legacy Cloud. It could also be configured to inject an easily testable provider instead. So, we have broken the direct dependency of MyConsumerClass to the Legacy Code Cloud.

The Result

So, what do we have? Our ConsumerClass, and the TextProvider, can now be worked with (and tested) as individual units. They can be maintained without having to get too deep into that Legacy Cloud. We now have the beginnings of infrastructure, the InversionOfControlContainer, which we can leverage against other maintenance tasks. The Legacy Cloud itself is now just that much more smaller – we have walled off a small section of order from the chaos of the rest of the cloud.

Conclusion

After you have spent some time working on breaking dependencies, you’ll find that code without dependencies is easier to maintain. Your classes get less complex, so they are easier to test and verify as correct. Because of fewer dependencies, changes to one part of the application won’t cause problems for another part.

Slides and sample code

What I learned from last night:

1. I’m not much of a moderator (I talk to much)
2. Code coverage is a art in divination
3. Mock/Stub/Fake Objects are hard to explain
4. Over use Mocks could be a code smell
5. The discussion format actually works pretty well for talking about unit testing
6. If you give geeks a chance to talk, they will talk

What I hope everyone else got from the topic:

1. Unit testing forces you to write better code
2. Unit testing forces you to use better object oriented principles

Test Technology

This was an early question, what technologies to use to test your code.  NUnit, MSUnit, and MBUnit were all mentioned and viable, and stable, technologies.  For mock objects (which you are going to need) there is Rhino Mocks and TypeMock.  I suggest Rhino Mocks over TypeMock for anyone who can’t purchase the full version of TypeMock (but there is a nice free version as well).

Then there are the helper technologies: TestDriven.Net and ReSharper are the main two, but apparently MSUnit’s runner isn’t bad either (I haven’t used it yet).  All of these tools make it easier to run your unit tests from inside Visual Studio, and each has other benefits.  TestDriven.Net has wonderful Reflector integration (a better object browser), and ReSharper…ReSharper is just a must have (that is me talking, not the group).

Code Coverage

Code Coverage, using tools like NCover (free version), tell you how much of your code base is tested.  This was one of the early questions.  How much of your code base should be tested?  Answer: it depends on the product.  My view is that a library (no UI element) should have +90% coverage, if there is a substantial amount of UI then the project can get down to 60%.  If your code coverage gets below that you just aren’t trying, or you need to rethink your architecture. 

I did talk a bit about code that was not really testable (not in an automated way anyway): UI, Database code, and external resource code are all potentially untestable.  More on this in a moment.

Database code is not testable if you can’t return the database to a known state (you can restore the database data). 

UI code testing should be avoided because UI tests have to be so bound to the UI that they are brittle.  So you end up spending a considerable portion of your development time fixing broken test. Brittle tests are to be avoided whenever possible.

Testing existing code

Probably the hardest question to answer from last night was: how do you test existing code bases.  And that came up over and over.  Do you start with integration tests and then work in unit tests, or the other way around. 

I will admit, most of the time when I talk about unit testing, I center it around new projects.  Unit test is hard enough with new code, testing old code that wasn’t written with unit test in mind is a migraine waiting to happen.

The audience did have some good advice though.  Pick parts of the project that you need to work on (say one class) and make that testable and tested.  Essentially you start creating silos of tested code.  The other suggestion (and I actually had a slide for this) was to get the book: Working Effectively with Legacy Code.  Finally, buy TypeMock — the big boy version, not the free-be version.  You’ll need it.

UI Testing

This is my treatise on writing unit tests for the User Interface:

1. Don’t do it until you are done with the UI.
2. Only test that the UI works in a basic sense.
3. You still have to test the UI by hand.

If you start writing UI tests while you are developing the UI, you will continually break the tests.  Writing the test by hand is none trivial, and using tools to write them is also error prone.  Finally, these tests can’t tell you if the UI is just bad.  Only exposure can tell you that.  Every developer should be forced to have to use their UI repeatedly so they know where is sucks.  You wont get that with automated UI tests.

That said, there are tools to help you test web user interfaces. Watin, Watir, and Selenium are all there to help.  We shall see if Team Systems adds anything to help with this (I’m hoping it does).

Testing Database code

This is essentially, testing code that touches the database.  Could be your NHibernate code, could be a stored procedure, could be ADO.Net code.  But really, this is just code that must touch an outside resource (database, file system, serial connection, etc) and there is no way, or point, to abstract it out any further.

The main point here was to have a way to get the data back to a known state.  Without that everything else gets much harder.

We also came up with a new term: SQL Ejaculation.  That is a pattern smell where an excessive amount of your HTML comes from you SQL database.  Like the entire site.  All of the HTML.  And you have stored procedures that simply build the HTML — in a 10,000 line stored procedure.  That is SQL Ejaculation.

Note: if this comes up in a Google search I might get worried.

After the meeting

We all went to Table Rock for a beer.  ‘nuf said, it is a great group.

Finally, to the guy who asked me a question after the meeting was over: I’m sorry, I just haven’t had to draw multiple, overlapping, transparent images on a win form using GDI.Net in a really long time.  I know it involves alpha-transparency values, but I haven’t done that in years.  Maybe you should look at WPF.

If you are looking for a similar product with a longer lineage, you could look up: StructureMap, Spring.Net, and Castle Windsor.  StructureMap is maintained by Jeremy Miller, who is a favorite blogger of mine (everyone should read his series on Build your own CAB).  Spring.Net is a port of an existing Java project, and Castle Windsor seems to have a lot of mind share.  Currently, Spring.Net is the only IoC library that I have used.

OK, definitions:
IoC: Inversion of Control, also called Dependency Injection.
This is based on a pattern found in the Gang Of Four books on Design Patterns.
You can read more about this pattern at Martin Fowlers web site:
http://martinfowler.com/articles/injection.html
Or on Wikipedia:
http://en.wikipedia.org/wiki/Inversion_of_control

The basic principle that IoC is used for is Loose Coupling.  If you have a multi-layered application, each layer should not have to know specific details about the other layers.  So each object in a specific layer will implement an interface that the IoC provider knows about.  Then, when a specific dependency is needed, you ask the IoC container for it (note: the IoC container is Tightly coupled) for the object to do the work.   If you look at the Asp.Net Membership Provider, you can see a simple example of that at work.

One of the ways that this can help you is that now all of your middle pieces can be swapped out without having to make massive code changes.  This also makes testing easier, as now you can more easily stub/mock/fake dependencies and just test your application logic.

Also, if you really get into the whole IoC thing, you will find that there are a number of other cool Computer Sciency things are possible.  Like Aspect Oriented Programming (unknown if Unity supports that or not).

Now with all of the other IoC libraries out there, why would I like the fact that Microsoft has created their own? 
One of the current issues with a lot of Microsoft software, especially the samples, is that they are all VERY tightly coupled (again, tight coupling is not good), but it is a pain to get around without an IoC solution.  And, as per Microsoft’s own structure, they will not use any software that they didn’t write or own.   So I’m hopeful that now they can start producing some software with loose coupling in mind, and make all of our lives easier.

All right, there are still a lot of definitions and ideas that could leave you puzzled, that happens.  That is also why we have google.  If you see something you don’t understand, leave a comment and I’ll try to clarify, or point you to someone else with a better explanation than I can give.

Finally, if you are looking for more information on this sort of thing, check out the session on Castle Windsor at Boise Code Camp on March 8.

See the contradiction?

These folks (and I have met many over the years) are quick to point out the flaws, inconsistencies, and downright disfunction of their current waterfall process.

“We get the requirements from the Business Analysts,” they say, “and they are never right.”

“We build an deliver to QA and move on to the next project,” they say, “and it always comes back with defects.”

“There is no such thing as defect-free software,” they say, “an in their world they are right.”

“It hurts when I hit my finger with the hammer,” they say while placing their index finger atop the next nail.

These same folks will dismiss Agile and iterative development practices in the next breath with words like “impractical”, “unrealistic”, or “chaotic”. Is this fear of change? Is it threatening to have the system you hate so much be threatened by an up-and-coming idea? This seems to me a bit like hating the king and leaving him in power for fear of who might will replace him.

This is one of the reasons I find it terribly important to discuss not just the benefits of all things Agile like Scrum and TDD, but to also introduce the history and practices of failed engineering projects that caused these things to emerge. This provides a pathway to enlightenment for the most diehard anti-Agilista. Once we can establish the history, theory, demonstrated success, and techniques, engineering minded folks are more able to see these Agile practices as real tools for their toolbox.

Another useful technique is to start these folks off with engineering process first, not methodology changes. Almost everyone can agree to the demonstrated value of TDD. Once a surly developer sees TDD as a small, iterative feedback loop, we can start asking why the next level of the feedback loop isnt’t happening with automated builds. Then Continuous Integration. Then iterative delivery to a product owner. Then Agile because by now they are already there without knowing it.

Leading with process in a top down implementation can be ineffective when selling to grizzled engineers. Let’s help people stop hitting their fingers before we try to get them to build something beautiful.