Take the 2-minute tour ×

Getting started with TDD and I want to ground up a Repository-driven Model. However, how can I use NUnit to effectively say:


I want to create tests for each domain model (E.g. ICarRepository, IDriverRepository), etc.)

Does this actually make sense?


share|improve this question

8 Answers 8

up vote 4 down vote accepted

TDD means you drive your development (design) by proceeding in a test-first manner, meaning you

  1. Write the outline (methods) of your class you want to test
  2. You create a Unit test for the sketch of your class
  3. You run your unit test -> it will fail
  4. You hack your class, just enough to make the test pass
  5. You refactor your class

This is repeated for each item.

share|improve this answer

That's not something you test with TDD. The test is can I call one of the methods of that interface on this class, and does it return the right thing.

share|improve this answer
Every time I've seen TDD used they do the chicken and egg scenario. E.g. They create a test saying does this method exist ... first red, then they implement it ... get it fail the expected result ... then get it to go green. If I want to test out my Repository should I start off by testing that the Interface exists? –  Cat Man Do Jul 10 '09 at 15:41
Show a link. I think that's ludicrous. –  John Saunders Jul 10 '09 at 15:44
More to the point, in "pure" TDD, you don't decide ahead of time that you're going to create some interface. You start by writing a failing test. If you need to do some data access to make the test pass, and if you've decided you will use this pattern, then create the interface - with the one method you need. Then create the class implementing the one method you need. Then see the test pass, refactor, refactor, repeat. –  John Saunders Jul 10 '09 at 15:46
I think, Nissan Fan, you are taking the point a little too far. In the example you give the test is for a method, i.e. code. An interface isn't code, it's a declaration of a contract that any class implementing this interface will deliver the given methods. You don't test for declarations, you test code. –  Lazarus Jul 10 '09 at 15:47
I would imagine that's the case only in dynamic languages, where the test will run and fail if the method doesn't exist. In a static language, that interface, and the method called off of it HAS to be there before the program will even compile. You're testing for its existence implicitly simply by referencing it in other tests, and compiling the project. –  Jeremy Frey Jul 10 '09 at 16:04

I would say that the compiler 'tests' (and I know that's a contentious statement) the interfaces existence when it tries to compile a class that implements it. I would expect to explicitly test for the interfaces existence in a test as it doesn't prove anything. You don't test that a class has been defined, you do test the methods on a class.

share|improve this answer

The existence of interfaces is implicity tested every time you use the interface in a test. For example, before the interface or any implementations of it exists, you might write a test that says, in part:

ICar car = new Convertible();

This establishes the existence of the ICar interface - your test won't compile until it's created - and that Convertible implements ICar. Every method on car you invoke will elaborate more of the interface.

share|improve this answer

You could write something like the following:

void AssertSomeInterfaceExists(object domainObject)
    Assert.IsTrue(domainObject is ICarRepository);

You can write this test and it will fail afterwards if someone changes your domain object to no longer implement ICarRepository. However your other unit tests, which depend on your domain object implementing this interface, will no longer compile, which would make this test somewhat redundant.

share|improve this answer

You don't need to test whether your interface exists or not. You aren't actually "testing" anything there.

share|improve this answer

What happens if your domain object doesn't require data access code. An example- a shopping cart?

share|improve this answer

You could use reflection to divine the existence of an interface, but that seems like stretching the idea of TDD.

Remember that TDD is about making sure that functionality holds over time, not about asserting a particular design pattern is applied. As Juri points out, the test isn't the absolute first thing you build.

share|improve this answer

Your Answer


