TDD, What are your techniques for finding good tests?

Question

I am writing a simple web app using Linq to Sql as my datalayer as I like Linq2Sql very much. I have been reading a bit about DDD and TDD lately and wanted to give it a shot.

First and foremost it strikes me that Linq2Sql and DDD don't go along too great. My other problem is finding tests, I actually find it very hard to define good tests so I wanted to ask, What is your best techniques for discovering good test cases.

Answer 1

Well, going by the standard interpretation of TDD is that the tests drive your development. So, in essence you start with the test. It will fail, and you will write code until that test passes. So it's kind of driven by your requirements, however you go about gathering those. You decide what your app/feature needs to do, write the test, then code until it passes. Of course, there are many other techniques but this is just a brief statement about what is typically thought in the TDD world.

Answer 2

Test Case discovery is more of an art than a science. However simple guidelines include:

• Code that you know to be frail / weak / likely to break
• Follow the user scenario (what your user will be doing) and see how it will touch your code (often this means Debugging it, other times profiling, and other times it simply means thinking about the scenario) - whatever points in your code get touched by the user, those are the highest priority to write tests against.
• During your own development the tests you ran that resulted in bugs you found - write tests to avoid the code regressing again with the same behavior.

There are several books on how to write test cases out there, but unless you are working in a large organization that requires documented test cases, your best bet is to think of all the parts in your code that you don't like (that aren't "pure") and make sure you can test those modules thoroughly.

Answer 3

I regularly write tests for third-party APIs. That way, when the API updates, I know whether I'm going to break or not.

Answer 4

Think. Read the code. Question yourself: e.g. can this pointer never be NULL here ? What happens if this method is called before the initialization ?

Don't make assumptions such as "this file will always be there". Test.

Think about edge cases, boundaries, negative values, overflows ...

Bug are often grouped by cluster. Look around when you find one. Also look for the same kind of bug in other locations.

Answer 5

Set your mind to the actual goal of testing: Finding bugs.

Be creative at imagining what could make your program fail.

Your tests must find bugs, not confirm that your program is OK.

Answer 6

I think this is a useful technique:

Using contracts and boolean queries to improve quality of automatic test generation

---

Reference: Lisa (Ling) Liu, Bertrand Meyer and Bernd Schoeller, Using contracts and boolean queries to improve the quality of automatic test generation, in proceedings of TAP: Tests And Proofs, ETH Zurich, 5-6 February 2007, eds. Yuri Gurevich and Bertrand Meyer, Lecture Notes in Computer Science, Springer- Verlag, 2007.