TDD - One test at a time or make a batch?

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

I'd vote for the first one as YAGNI comes to mind with why the second one could be problematic as that can take a long time to write all the tests first.

Answer 2

Normally you would want to develop one test at a time. In a scientific setting, you isolate one variable and test on that variable. The same should apply to programming. First, solve one problem, and then expand onto other problems.

There are many reasons for this method is beneficial to the development process:

1. Easy to Debug
2. Focus on one idea at a time, not really complicated
3. It uses the Bottom Up approach, allowing smaller things to build up to a bigger product.

Answer 3

Personally, I have found that writing a single test at a time helps me to stay focussed on the feature I am working on, rather than trying to bang out a batch of tests at once. I like the rhythm/flow of single tests better, and it helps to aviod any feature creep that may be introduced when writing a number of tests at one.

Answer 4

The first one. It will help you to better understand the functionality you are currently implementing as you have to think about what you are trying to test. If you do all at once it will be too much cognitive overhead!

Answer 5

• 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.

Answer 6

One at a time for TDD.

Write a test - write code to pass that test, rinse and repeat until all tests pass. Once you run out of tests then refactor your code.

Answer 7

In a perfect development team (rephrase: in my perfect development team), I would be pair programming with one person being the tester and one being the production code developer. The tester would write a simple test for the production code logic and the production code developer would write the simplest thing to satisfy the test. Once that is done, both parties would check in their code. Then refactor both test and production code. Then check in. Then continue with the test.

Test -> Production Code -> Check In -> Refactor -> Check In -> Repeat

Answer 8

I write a single test first, then make it pass, then I refactor.

Working to make a single test pass allows me to focus on the capability the test is demonstrating.

When I have several ideas for the next test, I write then as test placeholder and/or as comments, eg:

// test_foo_with_negative_value(void)

Then I pick up one, implemented it ... I can either pick up the simplest one, to progress, or a totally different one, to see if my design can handle such as case.