In TDD should I have to write Test first or Interface first?

Question

I am learning TDD using c#, as far as I know test should drive the development, that is first write a failing test after write the bare minimum code to pass the test then do refactoring.

But it is also said that "Program to Interface, not Implementation", so write an interface first. This is where my confusion starts, If I am writing Interface first then it is violating two things

1. The code that is written for interface is not driven by test.

2. It is not the bare minimum obviously i can write it with a simple class.

Should I start by writing tests for interface also ? without any implementation what am I going to test ?

If this question sounds silly sorry for that, but I am utterly confused. May be I am taking things too literally.

Answer 1

Your first violation ("The code that is written for interface is not driven by test.") is not valid. Let's use a trivial example. Suppose you're writing a calculator class, and you're writing an addition operation. What test might you write?

public class CalculatorTest {
    @Test
    public void testAddTwoIntegers() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 2)
        Assert.assertEquals(4, result);
    }
}

Your test has just defined the interface. It is the add method, see? add takes two arguments and returns their sum. You might later determine that you need multiple Calculators, and extract an (in this case) Java interface at that time. Your tests shouldn't change then, since you tested the public interface of that class.

At a more theoretical level, tests are the executable specification for a system. Interfaces to a system should be driven by the users of that system, and tests are the first method you have to define interactions.

I don't think you can separate interface design from test design. Defining interactions and designing tests for them are the same mental operation - when I send this information into an interface, I expect a certain result. When something is wrong with my input, I expect this error. You can do this design work on paper and then write your tests from that, or you can do them at the same time - it doesn't really matter.

Answer 2

What are we doing when we write an interface? Are we writing code, or are we designing?

I'm not a fan of the notion of Test Driven Design, but I love Test Driven Development. Personally, I've gotten my best results when I design the class up front by designing the interface before I write a test. I don't count the interface as code. The interface is a design that I will be implementing using TDD. Its likely to change an evolve as I work, but it is my roadmap (along with my test list).

I'll stop before I start to rant, but hopefully that's a helpful way for you to think about it.

Answer 3

In TDD should I have to write Test first or Interface first?

It all depends on how orthodox / religious you want to do TDD.

I am learning TDD

Since you are learning, you should experiment to get a personal workflow, which works for you.

1. If you want to do it according to the books, you write at first a test, which obviously will fail, because you are starting with no code at all. Then you write some code to make the test pass. If that is done, you are free to refactor the existing code, since you have a test which provides some kind of safety-net for refactorings. Deciding to use an Interface is some kind of refactoring.

2. Besides TDD or not: The question, whether to use an interface or not isn't interesting in the first place. Of course if you are sure, you have different behaviour you want to spread across several objects, it makes sense to think about using an Interface: For example, if you have some kind of output to different destinations, it makes sense to implement it via an interface Writer and have different classes for the output (FileWriter, Printer etc.). Although it is a common saying to write to an interface, but that doesn't mean: use an interface for everything. Sometimes it is one level of indirection to much. Btw. the same goes for services. But that's a different topic.

3. On the other hand, you could develop test driven in another way: design your code for testability. Which means, you write code, which is easy to test - although you write the tests afterwards. It doesn't matter if you write tests beforehand or afterwards, as long as you test anyways.

Answer 4

TDD or BDD would mean Doing your domain interfaces first and then writing tests against them by my interpretation. an interface's implementation has an expected behavior.

it's still test before code because an interface contains no testable logic it is the structure you write a test against.

I Would Do it as follows

1. Write the Semi Formal Behavior (Given:When:Then:)

2. Write the Interface (to host behavior encapsulating method)

3. Write the Test it Identifies (input the given, call the when, test the then)

4. Write/Alter the Concrete (Class that implements the interface) to Pass the Test

Answer 5

Never write tests before you've designed the interfaces. When you are thinking about what kinds of tests to write (test design) you should not also be simultaneously designing (architecting) your application. Don't think about two things at the same time. Have you heard of separation of concerns? It applies not just to the physical structure of your code but also to your thinking process.

Decide how your application should be designed first. This means that you design your interfaces and the relationships between these interfaces. Until you've done this you should not start thinking about tests. Once you know what your interfaces are then you can either first creatw them and then write tests against them or write tests first and then create them. In the latter case obviously you won't be able to compile the tests. I see no harm nor any violation of TDD philosophy in creating the interfaces before the tests.

Answer 6

Its okay to write the interface/code/test at the same time as long as their incorporation into the project is atomic.

Unless your boss is religious about TDD, in which case you probably have to write empty interface -> test -> minimal code (pointless step) -> more tests -> more pointless code -> more tests -> finally write the real code -> done.