Question

For unit tests should you;

Write a test. Write code to pass it.
Refactor.

Or

Write all your known tests. Make one
pass. Refactor.

I ask this because TDD states you stop writing code after all tests pass but this point is unclear.

Edit

One thing I think TDD focuses on more for this “rule” is in relation to stories/tasks no? Does anyone agree?

A few months later

A routine I’ve gotten into after seeing a screencast (I’ll try and find the link) on the subject is as follows.

• Write the names of the tests/behaviour/functionality at the
  top of the test class.
• Cut and paste the test name.
• Complete the test.
• Repeat until the list is empty.

Example using C#, should be generic enough however.

// Login page should not allow blank password    // This would be removed when cut/pasted.
// Login page should not allow blank username
...

[TestFixture]
class LoginPageTests {

    [Test]
    public login_page_should_not_allow_blank_password() {
        // Test code...
    }
}

Answer 1

• Write just enough of a test for the test to fail, usually this is because your code does not compile
• write just enough code to make your test pass
• repeat

These are the rules of TDD. This means that you are only ever writing one unit test and one bit of code at a time and doing this iteratively.

The point of TDD is not writing tests, it is using your tests to drive out the design. The idea is that once all your tests pass and they cover all the functionality you know that your code is also complete. Without tests, how do you know when you are done. So, when you feel that you have tested everything, stop.