CODEWITHSUNDEEP
c#tddnunit
Keith Adler
Keith Adler

Reputation: 21178

TDD - Test Existence of Interface

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

SomeInterfaceExists()

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

Does this actually make sense?

Regards

Upvotes: 0

Views: 623

Answers (8)

Patrick McDonald
Patrick McDonald

Reputation: 65441

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.

Upvotes: 2

Carl Manaster
Carl Manaster

Reputation: 40356

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.

Upvotes: 2

Jim
Jim

Reputation: 3170

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

Upvotes: 1

Lazarus
Lazarus

Reputation: 43094

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.

Upvotes: 3

Dan Davies Brackett
Dan Davies Brackett

Reputation: 10071

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.

Upvotes: 0

Juri
Juri

Reputation: 32920

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.

Upvotes: 4

RichardOD
RichardOD

Reputation: 29157

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

Upvotes: 0

John Saunders
John Saunders

Reputation: 161791

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.

Upvotes: 4

Related Questions