TDD. When you can move on?

Question

When doing TDD, how to tell \"that\'s enough tests for this class / feature\"?

I.e. when could you tell that you completed testing all edge cases?

Answer 1

On some level, it's a gut feeling of

"Am I confident that the tests will catch all the problems I can think of now?"

On another level, you've already got a set of user or system requirements that must be met, so you could stop there.

While I do use code coverage to tell me if I didn't follow my TDD process and to find code that can be removed, I would not count code coverage as a useful way to know when to stop. Your code coverage could be 100%, but if you forgot to include a requirement, well, then you're not really done, are you.

Perhaps a misconception about TDD is that you have to know everything up front to test. This is misguided because the tests that result from the TDD process are like a breadcrumb trail. You know what has been tested in the past, and can guide you to an extent, but it won't tell you what to do next.

I think TDD could be thought of as an evolutionary process. That is, you start with your initial design and it's set of tests. As your code gets battered in production, you add more tests, and code that makes those tests pass. Each time you add a test here, and a test there, you're also doing TDD, and it doesn't cost all that much. You didn't know those cases existed when you wrote your first set of tests, but you gained the knowledge now, and can check for those problems at the touch of a button. This is the great power of TDD, and one reason why I advocate for it so much.

Answer 2

A test is a way of precisely describing something you want. Adding a test expands the scope of what you want, or adds details of what you want.

If you can't think of anything more that you want, or any refinements to what you want, then move on to something else. You can always come back later.

Answer 3

that common sense, there no perfect answer. TDD goal is to remove fear, if you feel confident you tested it well enough go on...

Just don't forget that if you find a bug later on, write a test first to reproduce the bug, then correct it, so you will prevent future change to break it again!

Some people complain when they don't have X percent of coverage.... some test are useless, and 100% coverage does not mean you test everything that can make your code break, only the fact it wont break for the way you used it!

Answer 4

Alberto Savoia says that "if all your tests pass, chances are that your test are not good enough". I think that it is a good way to think about tests: ask if you are doing edge cases, pass some unexpected parameter and so on. A good way to improve the quality of your tests is work with a pair - specially a tester - and get help about more test cases. Pair with testers is good because they have a different point of view.

Of course, you could use some tool to do mutation tests and get more confidence from your tests. I have used Jester and it improve both my tests and the way that I wrote them. Consider to use something like it.

Kind Regards

Answer 5

Kent Beck's advice is to write tests until fear turns into boredom. That is, until you're no longer afraid that anything will break, assuming you start with an appropriate level of fear.

Answer 6

Well, when you can't think of any more failure cases that doesn't work as intended.

Part of TDD is to keep a list of things you want to implement, and problems with your current implementation... so when that list runs out, you are essentially done....

And remember, you can always go back and add tests when you discover bugs or new issues with the implementation.