[sethkojo]

Maybe you're over thinking it? It sounds like you're already doing the right things.

All the details might not be filled in, and there are surely things I overlook from the high-up view, but for the most part I already envision the solution.

The design part of TDD is just the expectations. So if you were to test an add function for example, you might write something like

  assertEqual(add(5,2), 7)
  assertEqual(add(-5,2), -3)
  assertEqual(add(5,-2), 3)

before actually implementing the function. So here the design is that the add function takes 2 arguments. That's it.

For other things like classes, your expectations will also drive the design of the class -- what fields and methods are exposed, what the fields might default to, what kinds of things the methods return, etc. Your expectations are the things you saw in your head before you start coding. So it's pretty much the same as what you do already. The benefit of TDD is in knowing that you have a correct implementation and you can move on once things are green.

One thing that's easy to misinterpret is that TDD doesn't mean writing a bunch of tests before writing any code...That's pretty much waterfall development. TDD tends to work best with a real tight test-code loop at the function level.

[ams6110]

Incidentally for functions like that, if you have an environment that supports a tool like QuickCheck[1], it's a great thing to use. "The programmer provides a specification of the program, in the form of properties which functions should satisfy, and QuickCheck then tests that the properties hold in a large number of randomly generated cases."

1: http://www.cse.chalmers.se/~rjmh/QuickCheck/

[collyw]

Why is that TDD examples always test stuff that is pretty much useless? I don't need to check an add function. I am pretty confident it will work as is.

If you can find me a more useful example on somewhere then please show it to me.