IMO, anyone new to TDD hear it's mantra(Red-Green-Refactor) will be put off by the "Write a failing test first"(Red). Say what?!

This first step(Red) I think, is a critical reason why most developers doesn't want to do TDD(I didn't at first). I mean, why would you want to write a failing test? Shouldn't it be "Write a test w/c expresses what you expect from your code?"

Case in point, say you want to test a Sum function, a newbie following write a failing test would naively write this one:

[Test]

public void SumTest()

{

  Calculator total = new Calculator(5);

  int result = total.Sum(5);

  Assert.AreEqual(5, result);

}

--

The preceding will fail because of either:

1.) Calculator class has not yet been created

2.) Sum method is not yet created

2.) or if 1 and 2 are true, it will fail because  5!=10

I've accomplished, Red(failing test), now I have to make it Green(passing), what I do is change the: AssertEqual(10,result); and it will pass. Being a newbie at TDD, I've committed several mistakes:

1.) I didn't follow that, a test shouldn't be altered(only if it's a wrong test), alteration should be in the code to be tested.

2.) The first iteration of test itself doesn't make sense, why would I assert 5 == 10? Coz, I want to make a failing test, that's why.

It should've been written as Assert.AreEqual(10,result); in the first place.

I'm writing this rather lengthy response, since this are the steps I was doing before and had to force myself to make sense of my tests. It was the later iterations of my venture to TDD that made me realize why it shouldn't be a "Make a failing test" and the book "Refactoring to patterns" further clarified it to me(newbie TDD practioneer) that "Red: You create a test that expresses what you expect your code to do."

If you've read my previous post s here, you'll notice that I advocate code testability and TDD. One of

I made that observation, while doing PHP TDD-style, in my previous post . In this interview with Dave