Writing junits in Test Driven Development before writing actual code?

Question

Folks it is always said in TDD that

we should write junits even before we write the actual code.

Somehow I am not able to understand this in right spirit. I hope what it means is that you just write empty methods wih right signatures and your test case is expected to fail initially

Say in TDD approach i need to get the list of customers.

As per my understanding i will write the empty method like below

public List<CustomerData> getCustomers(int custId){

return null;
}

Now i will write junit test case where i will check the size as 10(that i am eactually expecting). Is this Right?

Basically my question is in TDD, How we can write junit test case before writing actual code?

Answer 1

I hope what it means is that you just write empty methods wih right signatures

Yes. And with most modern IDEs, if you write a method name which does not exist in your test, they will create a stub for you.

Say in TDD approach i need to get the list of customers. whats the right way to proceed?

Your example is not quite there. You want to test for a 0-length array, but you already return it: you should first return null, the test will obviously fail.

Then modify the method so that the test succeeds.

Then create a test method for customer add. Test fails. Fix it. Rinse. Repeat.

So, basically: with TDD, you start and write test that you KNOW will fail, and then fix your code so that they work.

Recommended read.

Answer 2

Often you'll write the test alongside the skeleton of the code. Initially you can write a non-functional implementation (e.g. throw an UnsupportedOperationException) and that will trigger a test failure. Then you'd flesh out the implementation until finally your test passes.

You need to be pragmatic about this. Obviously you can't compile your test until at least your unit under test compiles, and so you have to do a minimal amount of implementation work alongside your test.

Check out this recent Dr Dobbs editoral, which discusses exactly this point and the role of pragmatism around this, especially by the mavens of this practise (Kent Beck et al)

A key principle of TDD is that you write no code without first writing a failing unit test. But in fact, if you talk to the principal advocates of TDD (such as Kent Beck, who popularized the technique, and Bob Martin, who has taught it to thousands of developers), you find that both of them write some code without writing tests first. They do not — I should emphasize this — view these moments as lapses of faith, but rather as the necessary pragmatism of the intelligent developer.