Planning unit tests with TDD

When you approach a class you want to write, how do you plan its unit tests?

Are there formal templates which you follow or do you use pen and paper/notepad?

I am lookin开发者_如何学Cg for some way to let other programmers/QAs know what tests should be implemented (and if something was overlooked it can be easier to spot it).

With TDD, tests drive the feature you are writing. If you're needing to write formal templates for it, then chances are you're not entering into the spirit of things!

TDD should be used to generate the test cases as you write the code. Simply put, before you write the next line of code, encode in a test what the code should do.

Check out Bob Martin's bowling game example which should give you more of a feel for TDD.

I do not think that having a template goes well with using TDD. I assume that you have read Kent Beck's Book on Test Driven Development by Example. If no please do so.

But the general idea is simple. When we start a class, we will have a general idea on the responsibility of the class. This is the steps that we use:

1. Have a general idea on class responsibility and use that information to name the class.

2. Create a test case for this class.

3. If you start with a concrete information on what the units inside the class are, just write those stubs inside the class and write test cases for those stubs. Initially all of it will fail and the signatures for most of those methods will change. That's the whole idea.

4. In most cases, the developer may not have that degree of information. In that case, it's OK to start writing code in the First Test. Once the test passes, then migrate the logic to the class.

So what I am driving at is, the whole point of TDD is to make the development process more organic. The class grows, with the knowledge on what it should do. Having a formal template, or writing things down, will probably not help.

The only thing I could think that you could do, is to sit with your developers before each iteration and come up with a pretty detailed idea on each of the component classes and its responsibilities (we only use this discussion to finalize public APIs).

If you want to know the quality of test cases written by your developer, then you can conduct an ad hoc code review to see if the classes are correctly broken down to units and all the units are tested.

TDD is not the methodology you are looking for ;-)

way to let other programmers/QAs know what tests should be implemented

This statement implies you are after tests, but TDD itself is driven by requirements and produces features - the fact that it also produces a suite of tests is an incidental (but hugely powerful) appendage which happens to result in a regression suite.

Although TDD harnesses 'tests' to drive development of code, you do not need to specify tests up-front. Even if you did (and sometimes is helpful to 'thinking' to do so) your programmer may not need to write all the tests in order to produce the desired behaviour in the code. Indeed, in TDD, you are encouraged to stop work when all the tests pass - you need not keep on writing tests only to find they already pass; that is something akin to makework.

Also, the other side-effect of TDD is in having (and continuously running) a regression suite. If at a later date a bug is found, it makes it easier, just by having a test suite, to write another test which demonstrates the bug with a failing test. Once the bug is fixed, the test should pass - along with all the other tests in the suite.

You cannot commit to TDD and let others do the unit testing. This requirement of yours strongly suggest that You haven't understood the TDD paradigm.

In my (admittedly fairly new) experience

• You write test that, if passed, will confirm your initial understanding of the target funcitonality. Not a single line of production code is written at this point.
• You then Implement the production code so the unit tests are passed.
• If your understanding evolves, you then change your unit tests or/and add new ones
• You then implement the changes in the production code so the tests will pass
• By then, it is not forbidden to write additional unit tests, if you discover that parts of your production code are not covered.
• Remove tests that no longer make sense.
• You arrive at beautiful crisp and clean code :o)

TDD is NOT a QA method; It is a way of DEVELOPING. The whole idea is that the unit test guide the development process. So you really can't let others do the unit tests for you.

I start by designing the class first, usually with a simple UML class diagram. I try not to make the diagram just detailed enough so that I can run tests against it (e.g. params and return types specified for each method, and I know how the method's behavior affects object state).

Then, I write unit tests. Generally when it comes to automated testing you should have 1 test method for every method defined in your class. As far as convention goes, if I have a method in my class called myMethod, then my unit test method will be called testMyMethod.

I write unit tests using what I know about the method's intended behavior, and then write the method and check to make sure that it passes the unit test.