> My beef with TDD is the same as my beef with a lot of estimation techniques. They really need for you to have done the thing before. Faith that you "know what tests are needed" is surprisingly loaded.
Why would you nee to know what tests are needed? Just about any bit of functionality you can come up with to implement you should be able to come up with a test to test it. It's not really harder to know what code to implement than it is to know what test to exercise that implementation.
And at any point in time you only need to think of a single test before you're back to coding. It's not like you need to plan out 50 tests up front. Whatever the next handful of lines of code you're going to write write a test for that first, then write those same lines. Then pick the next handful via test, then write them.
I don't understand the difference in knowledge at all.
The best example I can think of on this, is to look up that TDD creation of a Sudoku solver. This is collected in an old HN post at https://news.ycombinator.com/item?id=3033446.
It is reasonable to think you can know what functionality you need to test. And, for certain, if you know the boundaries of the system you are building, you will know some. That said, there is a tendency to build more boundaries than needed in our industry, period. Would be like a community garden that thought they should arrange things by type of plant that will be created by the community. When the actual divisions should be on how many community members you will have.
Fair, "best" is clearly the wrong word there. A pointed example, then? :D
That said, I'm more than game for alternative examples. Have any that show benefits? Most examples I ever see fall, at best, into drawing the rest of the owl.
Why would you nee to know what tests are needed? Just about any bit of functionality you can come up with to implement you should be able to come up with a test to test it. It's not really harder to know what code to implement than it is to know what test to exercise that implementation.
And at any point in time you only need to think of a single test before you're back to coding. It's not like you need to plan out 50 tests up front. Whatever the next handful of lines of code you're going to write write a test for that first, then write those same lines. Then pick the next handful via test, then write them.
I don't understand the difference in knowledge at all.