I am no TDD expert, but I find it useful in forcing me to think through the design of classes and how they should interact - before implementing it.
It is hard to write tests if you still don't have a clear idea how it will all work in the end, but I use that as an incentive to iterate on the design in my head or on paper until I actually do have some confidence of how the final design will be.
Sometimes I need to change things up and have to change the tests as a result, and this all adds overhead, but I usually end up appreciating a better design with TDD as opposed to when I just start coding with a sense of how the design should be and figure out things as I go.
Finally, I find it very tiresome to write tests after the implementation is done, since it's all working now and I want to start on The Next Thing. Looking back, I have very rarely written tests after completing the implementation first. With TDD it's kind of reverse, I get the satisfaction of seeing progress as I pass more and more tests - and it is almost bordering to fun. Almost.
the design of classes and how they should interact
That quote there is key to what I was saying. You are talking about class*es* plural, and the interactions between them. To me, that's an Integration Test and not a Unit Test.
Integration Tests I absolutely agree that Test-First TDD works great for. Write the tests for the feature as a whole, and then implement the individual units to make it work.
And I know full well that Test-First TDD works wonders at the Unit Test level for a lot of people. And that's fine. I'm just not one of them, and that's fine too.
What I meant to say, is that I use TDD for both unit testing and integration tests. Once the interaction of classes is defined in my design, then I know better what each class should be responsible for and can start unit testing those.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am no TDD expert, but I find it useful in forcing me to think through the design of classes and how they should interact - before implementing it.
It is hard to write tests if you still don't have a clear idea how it will all work in the end, but I use that as an incentive to iterate on the design in my head or on paper until I actually do have some confidence of how the final design will be.
Sometimes I need to change things up and have to change the tests as a result, and this all adds overhead, but I usually end up appreciating a better design with TDD as opposed to when I just start coding with a sense of how the design should be and figure out things as I go.
Finally, I find it very tiresome to write tests after the implementation is done, since it's all working now and I want to start on The Next Thing. Looking back, I have very rarely written tests after completing the implementation first. With TDD it's kind of reverse, I get the satisfaction of seeing progress as I pass more and more tests - and it is almost bordering to fun. Almost.
That quote there is key to what I was saying. You are talking about class*es* plural, and the interactions between them. To me, that's an Integration Test and not a Unit Test.
Integration Tests I absolutely agree that Test-First TDD works great for. Write the tests for the feature as a whole, and then implement the individual units to make it work.
And I know full well that Test-First TDD works wonders at the Unit Test level for a lot of people. And that's fine. I'm just not one of them, and that's fine too.
What I meant to say, is that I use TDD for both unit testing and integration tests. Once the interaction of classes is defined in my design, then I know better what each class should be responsible for and can start unit testing those.