This article serves as an introduction to the concept of Dependency Injection, and why you’d want to use it. It is not a getting started guide for using containers. If you’re interested in those, my personal preference is Castle Windsor and you can find their getting started guide here.

What are dependencies? Also referred to as couplings, dependencies are other modules that one module requires to fulfill it’s purpose.

Are dependencies bad? No, of course they’re not, otherwise we wouldn’t be able to create anything. However, highly coupled code can cause a lot of problems for your application.

If your code requires knowledge of how a dependency works, then your code is highly coupled. If your code is tied explicitly to an implementation, then your code is also highly coupled.

Take the following example:

public class ProductUpdater
{
	public void StoreChanges(Product product)
	{
	  SqlDataStore dataStore = new SqlDataStore();

	  dataStore.CreateConnection();
	  dataStore.OpenConnection();

	  dataStore.Update(product);

	  dataStore.CloseConnection();
	}
}

The above example is highly coupled to the SqlDataStore. Firstly, it directly creates an instance, which means there’s no way for us to replace that instance if we need to (I’ll come to why you’d want to do that in a bit). Secondly, it relies on a great deal of knowledge of SqlDataStore’s implementation. In this code we can see that you need to create a connection and open it before you can update the record; that’s quite a bit of implementation knowledge. If the SqlDataStore was to change so that the OpenConnection method created a connection if one didn’t already exist, then we’d need to change every caller of that code to remove the CreateConnection call; in large system situations like that can quickly lead to a fear of change and refactoring.

I mentioned directly creating an instance stops us from replacing it if need be. Well when would you actually want to do this? For those unfamiliar with unit testing, you probably haven’t encountered test doubles; there are different types of test doubles, but for the purposes of this example they’re interchangeable.

A test double serves as a swap-in replacement for one of your dependencies. These allow you to execute a piece of code under test, without having to worry about whether things are being put in your database, or e-mails sent for example. If your code is creating instances within methods, those instances cannot be replaced by a test double. Without that ability, testing becomes considerably more difficult.

Tightly tying your code to an instance of a class reduces the flexibility and reuse of your code. Take the above example, that same code could be used to update the product in a cache instead of the database; similarly, you could use an in-memory storage instead of a database for when you’re running in a test or demo environment. If only your method wasn’t so tightly tied to the implementation.

This is solved by using Dependency Injection, which is a part of the and Inversion of Control.

[DIP] seeks to “invert” the conventional notion that high level modules in software should depend upon the lower level modules. The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. — Wikipedia

Essentially, dependency injection allows you to stop instantiating your dependencies. Instead they’re “injected” into your object when it is instantiated itself. This allows the dependencies to be swapped out like we mentioned above.

So taking the original example, here’s a version of it that’s been updated to use dependency injection.

public class ProductUpdater
{
	private SqlDataStore dataStore;

	public ProductUpdater(SqlDataStore dataStore)
	{
		this.dataStore = dataStore;
	}

	public void StoreChanges(Product product)
	{
	  dataStore.CreateConnection();
	  dataStore.OpenConnection();

	  dataStore.Update(product);

	  dataStore.CloseConnection();
	}
}

The above implementation now allows us to create a test double, and replace the SqlDataStore in our tests. As I mentioned before, we could now easily push in an in-memory implementation without any changes to the code required.

We can take this further though, because we’re still tied to a concrete class. Lets make SqlDataStore implement an interface, so we can create other implementations.

public interface IDataStore
{
	void CreateConnection();
	void OpenConnection();
	void Update(Product product);
	void CloseConnection();
}

public class ProductUpdater
{
	private IDataStore dataStore;

	public ProductUpdater(IDataStore dataStore)
	{
		this.dataStore = dataStore;
	}

	public void StoreChanges(Product product)
	{
	  dataStore.CreateConnection();
	  dataStore.OpenConnection();

	  dataStore.Update(product);

	  dataStore.CloseConnection();
	}
}

Now our example is no longer specifically tied to a SqlDataStore, so we could quite easily pass it a FileSystemDataStore, or an InMemoryDataStore, or anything else that implements IDataStore. All that without having to touch a single line within the ProductUpdater.

That’s the power of dependency injection, and why you should stop hard-coding your dependencies.

There are a few problems with falling into this trap. Firstly, it’s very brittle. Secondly, you shouldn’t be concerned with the internals. Thirdly, it’s very time consuming.

To elaborate…

It’s brittle because you’re essentially writing a script of how the method is going to execute, which of course will change whenever you do any refactoring. So your tests break every time you make a change to your code, which is not only annoying, but will quickly lead to test cancer, where tests aren’t run or are commented out.

You shouldn’t be concerned with the internals, because as long as your method is doing as requested, you shouldn’t really care how it’s achieving it’s goal. Not bolting down the internals allows methods to be refactored without too much resistance from the tests. This will increase the signal-to-noise ratio, allowing failing tests to be representative of a problem greater than your basic refactorings.

Finally, it’s time consuming simply because you’re duplicating most of your work. All the time you spent writing the method (or the test, if done first) is then duplicated writing the tests (or code…). This is a pain, because as mentioned above, you’ll keep doing this work every time you change the method.

The hardest part is learning how to not do this kind thing blindly. There are plenty of times when you’ll need this kind of testing, but don’t make it your default! Test expectations, not implementations.

The DeleGrid is a control derived from the ASP.Net GridView, that delegates its data retrieval back out of the control. This allows the developer full control over the records that are retrieved, thus allowing proper paging to be implemented using whatever collection type you prefer.

Why the DeleGrid?

It came about because I wanted a nice way of implementing paging using NHibernate without having the grid know about it. I really didn’t want NHibernate to leave my data layer, so I needed a nice way of the grid calling my DAL with the paging parameters.

I didn’t want to utilise the ObjectDataSource because honestly, it made me feel dirty. I’m all for delegation and composition, but not when it means creating a control in my HTML that acts as a DAL. Additionally, I didn’t feel the ObjectDataSource was very type-safe, or refactor-friendly, with the method names and types exposed in the HTML. Granted, the IDE would probably pick it up, but I don’t want to risk a runtime failure on it.

Using the DeleGrid (aka The Example)

After getting the source or assembly and doing the usual song-and-dance, add a reference to the control to your page:

<%@ Register Assembly="JAGregory.Controls.DeleGrid"
  Namespace="JAGregory.Controls" TagPrefix="jag" %>

Then create an instance of the control, turning the paging on and setting the correct page size:

<jag:DeleGrid ID="grid" runat="server" AllowPaging="true"
  PageSize="4" />

Now you have a control set up, however it sill won’t bind correctly. So, you need to attach the event handlers in the code-behind.

protected override void OnInit(EventArgs eventArgs)
{
  base.OnInit(eventArgs);

  grid.TotalRecordCountRequest += delegate {
    // code to get total
  };
}

Starting with the TotalRecordCountRequest, this event is raised when the grid needs to know how many records in total your grid is going to be displaying. This number is the cumulative count of all the pages. I’m going to use a simple repository pattern to factor away my DAL logic.

The OnInit method is now:

protected override void OnInit(EventArgs eventArgs)
{
  base.OnInit(eventArgs);

  ProductRepository repos = new ProductRepository();

  grid.TotalRecordCountRequest += delegate {
    return repos.GetTotal();
  };
}

Now your grid knows how many records it has overall, however we still haven’t told it how to actually get the data. So now to put the code in the PageDataRequest handler. This event is raised when the grid is needing a new page of data, this will get called once on initial data-bind, then again every time you change the page (or sorting etc…).

The OnInit method is now:

protected override void OnInit(EventArgs eventArgs)
{
  base.OnInit(eventArgs);

  ProductRepository repos = new ProductRepository();

  grid.TotalRecordCountRequest += delegate {
    return repos.GetTotal();
  };
  grid.PageDataRequest += delegate(object sender, DataRequestEventArgs e) {
    return repos.GetRange(e.Start, e.Size);
  };
}

The event-handler receives an instance of DataRequestEventArgs, which contains the start index of the current page of data, and the number of records in a page. It also contains a SortField and SortDirection, for when sorting is enabled on the grid; however, we aren’t utilising them in this example.

Finally we just need to bind the grid on page load. We don’t re-bind the grid on post-back, due to that being handled internally in the DeleGrid.

protected override void OnLoad(EventArgs eventArgs)
{
  base.OnLoad(eventArgs);

  if (!IsPostBack)
    grid.DataBind();
}

That’s all there is to it!

You don’t need to use delegates, the normal event-handler syntax is fine (and probably preferred for larger examples). I just did it this way for brevity’s sake.

Further reading…

Testing

I’ve written a small number of tests that cover the implementation of the grid as best I can. There was only so-far I was willing to go to test the control, as it’s heavily tied to the ASP.Net implementation; which can get pretty messy for testing without using something like NUnitASP, which was a bit much for one control.. I’ve got coverage of about 85% of the code, which I’d say is pretty reasonable anyway.

Sorting

As mentioned above, you can implement sorting in your handlers by accessing the SortField and SortDirection properties of the event arguments.

DeleGrid.AlwaysRequestTotal

By default the DeleGrid only requests the total number of records on the initial data-bind, however if you see this as being a problem (such as with rapidly changing data-sets), you may want to set this property to true so it refreshes the total on every data-bind.

Downloads

The DeleGrid is open-source under the new BSD License; read the license for what you’re allowed to do.

You can download the source here: Download Source.
You can download the latest binary here: Download Binary.

The source is also accessible from Subversion at: http://jagregory.googlecode.com/svn/trunk/DeleGrid/ (using user jagregory-read-only)

All patches are welcomed with open arms!

Ricky Clarkson left me a link in a comment to one of his posts that ties in quite nicely to my recent Getting with it: Test Driven Development post.

Ricky makes the point that TDD can be dangerous, and can lull you into a false sense of security. I agree.

As with any technology, when used incorrectly it can cause more damage than not using it at all.

Ricky’s example should serve as a double-barreled warning. You can’t be test-driven only when it’s convenient, and you need to have good test coverage.

Being Test-Driven isn’t being Convenience-Driven

Just by being in a car with seat-belts doesn’t mean they’ll save you when you crash, you need to actually wear them.

You can’t pick and choose which parts of TDD you want to use, then be surprised when it lets you down.

If your boss comes storming in demanding a copy of the system, tell him to wait. Remember, it’s your hide on the line, if you give him a broken system you’ll be the one to pay. If he doesn’t understand testing, lie, tell him it’s building or something similar, it doesn’t exist until it’s finished.

Test coverage

There’s very little more important than good test coverage, without it you’re leaving yourself wide open for problems.

In Ricky’s example, he’s fallen into a common problem with test design. He’s only testing the expected outcome of his method. We’ve all fallen into this trap at some point, but it’s a dangerous place to be. Without full coverage, just as Ricky said, you end up with a false sense of security.

For full test coverage of a method, you really need to test it’s expected outcome, how it handles edge-cases, and how it handles bad data.

(assert (equal (point+ (point 999 987) (point 789 998)) (point 1788 1985)))

Had Ricky’s test suite included the above edge-case test, it would have caught the flaw in his method’s design, and been able to correct it. A few more like the above, to cover minus numbers and very low values, and his situation would have been greatly different.

If there’s a way you can improve testing, it’s to write more unit tests. Only leave those bits you really can’t test to integration. Everything else should be adequately covered.

In parting

Remember, using TDD isn’t an excuse to leave your common sense at the door. If you’re writing a method which you know is going to be used in several places, test those several places, give it very good coverage. If you’re writing a sum function like Ricky, you know how it’s going to be used, don’t just write if statements to cover all your input data, that’s using coding to make a test pass an excuse to write bad code.

On a personal note, test-driven development is something I should have started doing a long time ago, it’s certainly something that I’ve known about long-enough to be unable to claim ignorance. I take no pride in saying that my sole reason for not learning sooner is laziness. I bet I’m not the only one though. There’s a lot to learn, and not all of it is simply new tools, some of it is mental too; rewiring your brain isn’t an easy task.

Having broke through the pain barrier, I can now vouch for the other side and say it really is nicer.

So how would I convince my-self from six months ago, that test-driven development is a worthwhile pursuit? Well after a bit of ear twisting about being lazy, I’d have to raise the point of security. I don’t mean the “IM IN UR HARD DRIVE, STEALIN UR FILEZ” security, but the knowledge that you’re the one who’ll find bugs in your code, not the tester (or worse, the customer). A record of bugless (or bug-minimal) releases will bode well at your performance reviews. That, and nobody likes people finding problems in their code, so it’s best you find them first.

That all sounds rather selfish and egotistical. What about the team, the flexibility, and the clean structured code-base? I’m a big advocate of a clean code-base, and a well oiled team can’t be beat, but from experience, not everybody else feels the same way. Developers tend to respond more readily to two things: money, and fun. I’m generalising of course, but your average-joe developer isn’t an altruist, he isn’t going to go out of his way to help others. Give him the prospect of some extra cash, or even just the chance to break out of the mundane, and it’s a whole different game.

This was the turning point for me, where test-driven development past the point of being a nice-to-have practice and entered the territory of being something that could benefit me in my daily life. I also discovered it’s pretty fun too.

Test-Driven Development = Security in code = Security in your job

N.B. I shall not be held responsible for anyone who still proceeds to lose their job, even while practicing test-driven development.

One last thing that I haven’t mentioned. There’s a feeling. A feeling of joy, a reassuring warmth. You get this feeling often when you’re test-driven. Found a bug? Write a test. Test fails. Fix the bug. Test passes. You’ve fixed the bug; knowledge, safety, and security.

Learning to drive

When learning how to test drive your development, it’s important to know that you aren’t specifically learning a new tool as many people have put it. Not in the same respect as learning a new IDE or source control system. Test-driven development isn’t something physical. As I mentioned earlier, it requires you to rewire your programming brain. Although to successfully master test-driven development you are required to learn some physical tools (NUnit for example), the primary change will be a
mental one.

The most basic changes to your mental-model will be that your tests literally drive your code. You’ve probably heard it before, but you test first¹.

What follows is a simple run-through of how you’d test-drive some simple development, and how changes to a system would be handled.

I’m going to try to keep the code as terse as possible, as to not complicate the theory with execution. There will be some boilerplate code that I will not include, such as setting up the fixtures. Ron Jeffries provides a good introduction to NUnit for .Net developers.

The First Iteration

To set the scene: you’re a developer building a system for a very small shop. They’ve been working primarily from spreadsheets, but feel they’re ready to move on to a real system.

While other developers are creating the rest of the system, we’re tasked with creating the method for retrieving the price for the products. As this is a very small outfit, we’re only going to start with one product. Very small outfit.

We’re told that the product we’re going to be passed is an Apple, so following our mantra we’re going to write our test first.

[Test]
public void ReturnsCorrectPriceForApples()
{
  Inventory inventory = new Inventory();

  Assert.AreEqual(0.5, inventory.GetPrice("Apple"),
    "One apple should cost 50p.");
}

You can see that we’ve now written our first test, unfortunately this test will not pass yet as we can’t even compile.

Never fear, lets create the class.

class Inventory
{
    public double GetPrice(string product)
    {
        return 0;
    }
}

We’ve now created the class, so the code compiles and we’re able to execute our first test.

It failed. This one of the key steps in test-driven development. Make a test, and make it fail, then write the functionality required to make the test pass. Baring that in mind, we’ll now modify our code to allow the test to pass.

public double GetPrice(string product)
{
    return 0.5;
}

It passed, that’s one test under our belt.

You’ll notice that this isn’t a very good design, but we’ve written enough code for the method to work for it’s current usage. We’re letting the tests drive our code, which means we’re ending up with only the code we require. YAGNI: You Aren’t Gonna Need It².

The Second Product

Our implementation of GetPrice is painfully simple, so simple that we don’t even support multiple products. This worked fine for us while the customer only had one product, but they’ve now expanded and have requested their second product be added. Lets write another test to cover this new request.

[Test]
public void ReturnsCorrectPriceForSausages()
{
    Inventory inventory = new Inventory();

    Assert.AreEqual(2.99, inventory.GetPrice("Sausages"),
        "One pack of sausages should cost £2.99");
}

Once again, if we compile and run this test it will fail, because we’ve hard-coded the method to always return £0.50. So lets update the method to work for sausages too.

public double GetPrice(string product)
{
    if (product == "Apple")
        return 0.5;
    else
        return 2.99;
}

The test now passes.

Once again, this code isn’t pretty, but it does the job. We could implement this in a much better way, but we don’t have the time, there’s always more urgent things that need doing. What’s important in what we’ve just been doing is creating the tests, which serve as our safety net for when we eventually do decide to make this code nicer. We know that by re-running our tests, our code still works as it did originally.

Refactoring

Fast forward a couple of months in our systems life. The customer now wants some more products adding, after all there’s only so much you can do with apples and sausages. They’ve supplied us with a list of products, with their prices:

Looking at our code, we can easily see that this is going to get messy, fast. This is where we turn to refactoring our code.

“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”
—Martin Fowler

Test-driven development makes it easier for a developer to refactor, as the tests you create define a contract that the code must adhere to, any breaking of the contract is immediately noticeable.

Lets spend a small amount of time refactoring our current implementation to make it easier for future product additions.

class Inventory
{
    private Dictionary<string, double> products;

    public Inventory()
    {
        products = new Dictionary<string, double>();

        products["Apple"] = 0.5;
        products["Sausages"] = 2.99;
    }

    public double GetPrice(string product)
    {
        return products[product];
    }
}

We’ve now made the code a bit cleaner, and the design a little bit more flexible. If we now re-run our tests, we will see that everything still passes. We are safe in the knowledge that everything the customer requested previously still works. We’re now safe to proceed with their new request, adding the new products. Thanks to our refactoring, this change is nice and easy. First things first, we need to create our tests to cover this requirement.

[Test]
public void ReturnsCorrectPricesForOtherProducts()
{
    Inventory inventory = new Inventory();

    Assert.AreEqual(3.99, inventory.GetPrice("Potatoes"),
        "Potatoes should be £3.99.");
    Assert.AreEqual(1.27, inventory.GetPrice("Cola"),
        "Cola should be £1.27.");
    Assert.AreEqual(0.99, inventory.GetPrice("Bread"),
        "Bread should be 99p.");
    Assert.AreEqual(0.47, inventory.GetPrice("Milk"),
        "Milk should be 47p.");
}

As should be realising by now, this test is going to fail. After running to confirm, we need to update our constructor to include the new products.

You may wonder why we bothered to run the test when we know that it was going to fail. Well it’s a good practice to get into, because if you don’t actually witness your test failing, you don’t know for certain whether your test is actually correct. You might be testing the wrong thing. If your test passes when you expect it not to, you know there’s something wrong; but if you don’t catch it, your pass after your change won’t mean anything.

public Inventory()
{
    products = new Dictionary<string, double>();

    products["Apple"] = 0.5;
    products["Sausuages"] = 2.99;
    products["Potatoes"] = 3.99;
    products["Cola"] = 1.27;
    products["Bread"] = 0.99;
    products["Milk"] = 0.47;
}

After making this change, our test will now pass. We’ve now successfully completed our customer’s requirement, and our code has become a little bit more manageable in the process.

Boundary Conditions

The customer is happy with our implementation of their requirements, even if we can see some places for improvement, and the release date is looming. The customer starts integrating their existing data into our system. After importing the list of products from a spreadsheet, the system is given a thorough run through.

The customer noticed that after importing the list of products, whenever anyone bought an apple, the system crashed. After some investigation, it ends up the spreadsheet with the products had apples in all lower-case, while our inventory has it stored with an upper-case letter a.

This exposes a flaw in our testing logic. We’ve currently just been testing how we expect the method to behave under normal usage, but not actually testing how it will act if we pass it things other than what it’s expecting. Our tests should also be testing for invalid data and boundary conditions.

Boundary Condition: A problem or situation that occurs only at a extreme (maximum or minimum) operating parameter.

An example of a boundary condition would be supplying 1 and 12 to a GetDaysInMonth method.

Invalid Input: Anything outside standard operating expectations.

Using the same example as boundary conditions, invalid input would cover supplying -6, 0 and 76 to the GetDaysInMonth method.

We’ll write a test to cover the invalid input the customer encountered, we’ll pass in a valid product name, but one that’s capitalised incorrectly.

[Test]
public void ReturnsCorrectProductPriceWhenPassedIncorrectCasedName()
{
    Inventory inventory = new Inventory();

    Assert.AreEqual(0.5, inventory.GetPrice("AppLE"),
        "Should return price of Apples, 50p.");
}

Running this test will fail, as usual. So lets fix the code to allow case-insensitive product names.

public Inventory()
{
    products = new Dictionary<string, double>();

    products["apple"] = 0.5;
    products["sausuages"] = 2.99;
    products["potatoes"] = 3.99;
    products["cola"] = 1.27;
    products["bread"] = 0.99;
    products["milk"] = 0.47;
}

public GetPrice(string product)
{
    return products[product.ToLower()];
}

We’ve modified our constructor to set the product names as lower-case, then modified our method to convert the inputted product name to lower-case as well. This way our searches are case-insensitive.

Running all our tests should assure us that our existing code still functions, and we’re now safe from any case variations from the customer’s product list.

While doing this change, it’s noticeable that we’re also not handling the case for if a price is requested for a product that isn’t in the inventory. If this occurs we really should pass a message up to the GUI, so it can present the user with something.

Due to this being an exceptional situation, it’s ideally suited to an exception! Let’s write a test to handle this case.

[Test, ExpectedException(typeof(InvalidProductException))]
public void ThrowsAnExceptionForAnInvalidProduct()
{
    Inventory inventory = new Inventory();

    inventory.GetPrice("My Invalid Product");
}

We’ve introduced a new attribute to our test in this case, ExpectedException, this simply allows you to specify what exception you want a method to throw in the situation you’re testing.

Note: This test requires the use of a custom exception, I’m not going to show the implementation here as it’s simple stuff. I’ve chosen to use a custom exception so our “GUI guys” know what to capture for this case.

It’s generally regarded as good practice to wrap your internal errors in something that’s meaningful to the rest of the application, hiding the implementation details. An InvalidProductException is much easier to understand and implement than NullReferenceException, IndexOutOfRangeException etc. This is another topic in itself though.

To make this test pass, we need to update our GetPrice method to handle invalid products.

public double GetPrice(string product)
{
    if (!products.ContainsKey(product))
        throw new InvalidProductException("Product supplied, " + product +", is not in the inventory.");

    return products[product];
}

We’re now doing a simple check to see if the internal product Dictionary contains an entry for the requested product, if it doesn’t we’ll throw one of our InvalidProductException’s.

Running our test again will now assure us that our method throws an exception in these circumstances.

We can now return to integration and the customer can be assured that it all works.

Learning Conclusions

What have we witnessed in running through this little exercise?

1. How easy it is to test first – It’s really not that complicated. Once you’ve learnt to apply the restraint needed to stop yourself from just diving in, it’s easy.
2. The security you get from tests – If you’ve come from an environment that doesn’t have any code tests, you’re probably enjoying the reassurance that tests bring. You’re at least safe in the knowledge that you haven’t broken anything existing with your new features. The more tests you introduce, the more solid your base for making changes becomes.
3. Ease of refactoring – As with the above, it’s easy to refactor your existing code when you’ve got a suite of tests in-place.
4. Light-weight nature of your code – When you’re only coding to make your tests pass, you’re less likely to code features that aren’t required. This makes your code as light as possible.

Dealing with Legacies

Lets be honest here, nobody likes legacy code. You know the kind of code I mean. The code written by the mysterious and elusive previous developers. Usually it’s dire, sometimes it’s shocking, most of the time it’s untested.

Testing legacy code can be a nightmare in itself, but it is possible. What you need to remember in this situation is that you can’t be a hero. There’s no way you can create a test suite that covers the whole system, it’s just not feasible.

Your best approach to testing legacy code is an incremental one. If you find a bug in the system, write a test that fails because of it, then fix the code and run your test. That way you have a test that covers that bug, and you’re now safe from that bug showing up again. Eventually, if you continue this way, you’ll end-up with a nice suite of tests covering your common bugs.

Often the system you’re trying to test will be an unstructured mess, it’ll be very hard to separate out logical concerns. It may be possible for you to utilise mock and stub objects³ in these situations, which will help you break down the barriers. Sometimes even this isn’t possible, and these may be the cases where you’re either going to have to live with a few hundred lines of setup code for your tests, or live without automated testing, at least until you can rework the code to facilitate testing more readily.

Another form of legacy that you’re no doubt going to encounter is that of the legacy mind. How you write code may have been turned on its head by the introduction of test-driven development, and you’re going to slip back into your old ways every now and again. This happens to everyone at some point, but if you can force yourself to maintain your standards then you’ll eventually break the barrier and you wont look back. If I code without unit tests now, I feel an overwhelming sense of insecurity and dirtiness. It’s a good thing!

Recommended Reading

• Extreme Programming Roadmap Great resource, lots of discussion, including some from the greats.
• Martin Fowler Lots of good articles.
• Jeremy Miller Plenty of reading material, lots of insightful stuff. Rules of TDD: 1, 2, 3, 4
• Adventures in C#: Using NUnit Good introduction to using NUnit.
• Extreme Programming Adventures in C#, Ron Jeffries – Honest and friendly introduction to TDD and XP.
• Refactoring: Improving the Design of Existing Code, Martin Fowler – Refactoring bible.

References

¹ Extreme Rules: Test First, ExtremeProgramming.org

² You Aren’t Gonna Need It, Extreme Programming Roadmap

³ Mocks Aren’t Stubs, Martin Fowler