| > That said, I don't think TDD is a good way to figure out your API. There are plenty of ways to do it and one way that has worked well for me is in practicing TDD. So it is indeed one good way of doing it. There are also people who are inexperienced with TDD or who misunderstand it and implement it poorly. There are people who are just not ready to design APIs yet who are forced to learn on the job. None of those things invalidate what I said. If TDD doesn't work for you then you'll have to find what does and I hope that you test your software in a sufficient manner before deploying it. > In any case, it seems to assume that more tests are always better I think you're projecting your own opinions into the matter. There's nothing about TDD that prescribes what kind of tests one should write or how many. You could write acceptance tests and work from there if that suits you better. It's test driven development. The operative word is what we should focus on: testing is a form of specification and we should be clear about what we're building and verify that it works as intended. It comes from an opposition to other forms of verification that used to be popular: black box/white box testing where the specifications were written long before the software development phase began and when the testing happened long after the software was developed. That's where it's most useful: as a light-weight, programmer-oriented, executable specification language. |
Unless you're talking about the default state of failing tests when no implementation exists, I'm a bit confused as to how TDD helps with interface design.