Should I write tests before they will compile? [closed]

Question

I've been trying to follow a loose TDD workflow for one of my open source projects. It's an API for other programmers to use.

As such, one key aspect as well as making the API "work" is also designing how it will be consumed. I've heard some people say that writing tests before they'll compile is a waste of time and prone to constant rewrite until the API is stable. I've also heard that it should follow a workflow like so:

1. Write the tests which won't compile
2. Make it compile
3. Make it green

I've been trying to follow this workflow, but I end up with some weird things. For instance, in my API I have these two methods:

Handles(string pattern); //had this one already
Handles(IPatternMatcher pattern); //needed this one

I needed to get the second form of the method added to my API. So, I ended up with a dead simple test like so:

public void Handles_SupportsIPatternMatcher()
{
  var api=new MyAPI();
  api.Handles(new TestPatternMatcher());
}

Which seems like a waste after it gets implemented.

Should I continue following this workflow, or are there ways to improve it? How do I keep from writing tests that basically just check for compiler errors? Since it's a publicly consumable API, should I worry about tests like this?

Answer 1

No.

Do not write code that tests whether the compiler is working. Those kind of tests make a lot of sense if you are using dynamic languages (or dynamic features in a static language), where they will actually tell you that you forgot something, or refactored something into a failing unit test.

The point of the unit test execution is to fail the build if it is in error. If you have a compiler error in your code, the build will already fail. There is no need to second-guess it.