Bear with me, this is a beginner question: I'm a solo developer, quite familiar with C# and web development and I'm currently trying to shift to TDD since I believe I've understood the advantages in the long run. The classes I usually create do not implement any Interfaces (except from IDisposable and other standard candidates) since I never saw a need to do so. My projects are usually made up of a Website and a couple of class libraries, which only I consume.

Now I had a first look at TDD, and I'm feeling like to be pushed into a Lego-Cube-Box. I don't know where to start. Is an interface-based design required for unit-testing? What are mockups used for and are they required for unit-testing? I would be very glad if someone could explain the basics of test-driven-development and the steps required to get started. A further reading link would be highly appreciated as well.

+5  A: 

It's quite an extensive topic that I would advise getting a good book about.

I can recommend two:

Test-Driven Development By Example

Test-Driven Development in Microsoft .NET

Also see What is TDD?

As far as getting started with TDD. The fundamental concept is to understand why thinking about and writing tests BEFORE code is beneficial. Then the other major TDD processes such as how to write quality unit tests, where Mocking tools are useful, will be more understandable.

Thank you for the book links. I certainly will go get one of those.
+2  A: 

Some say you should only Mock interfaces. Some say that an interface-based design is better for testing an extensibility. Some people say a lot of things.

The fact is, you will probably have to make accommodations in your design to allow for testing, but that's not necessarily a bad thing.

You can mock classes, and I see no reason why you shouldn't, if it helps.

One thing that is more helpful is to use the so-called "Inversion of Control" design for your classes; this basically externalizes the dependencies of a given class, allowing you to change it for testing. This can certainly be done using interfaces, but its not strictly required.


I second the recommendation for Kent Beck's Test Driven Development By Example.

Also, on the topic of Mocks specifically I found the essay Mocks Aren't Stubs by Martin Fowler to be helpful when I was trying to figure them out. It has some very clear explanation and good examples (code in Java, but it's pretty general).

The Mocks aren't Stubs is certainly a good read. Thank you.

To understand mocking read this article by Paulo Caroli Complementing Unit Test with Dependency Injection and Mock Objects. For examples see this website

That URL links to a domain squatter. Is this the right one: ?
Sergio Acosta

The golden rule of TDD is do only what you need for the test to pass. That means, if you need an interface, then put it in there if it solves your problem. You will most likely need an interface when you are crossing boundaries. That is, when your objects need data from a web service or database, that is a big boundary to cross. You may even need to consider the file system a boundary and want to mock that out.


I'm in the same boat as the question author. I've read Kent's book, and it makes sense from the limited example provided, but it doesn't really help to get started on a non-trivial project. Where does one start?

Its me

I think the best you can do at the start is follow a book or try to create a small project for you to learn TDD. Another thing i found really interesting is to read other peoples code. Open source projects like :the castle project are really cool for this Also its quite likely that you actuallky do need interfaces in places you are not using them at the moment. Inversion of Control is another thing that you ll find useful when learning TDD becuase it helps decoupling the classes and mocking for UT hope this helps