3 ms·

I think we agree more than we disagree. I'm totally in favor of having a comprehensive test suite that ensures that further changes to the application won't bre

I think we agree more than we disagree. I'm totally in favor of having a comprehensive test suite that ensures that further changes to the application won't break already built features. I'm just of the opinion that unless you already know pretty much what the solution is going to look like it's not a good idea to build the test suite for the solution before you've built the solution itself. Building the test suite first locks you in to a particular way of organizing your code, and changing that organization is painful, because every time one of the externally facing APIs to one of your modules changes, you also end up having to change a bunch of tests. TDD works well for CRUD applications because there really isn't much new that's going on there. You're reading some data, validating it, manipulating it according to a fixed set of rules that you get from business analysis and saving it to a database. It's fairly straightforward to put tests around each of those stages. However, if you're making a program to solve a problem which is novel to you, it makes more sense to write the tests after you have a solution, since it's likely that your first few attempts to solve the problem will have to be heavily refactored before you have something that works in the way that you want.

jacques_chester 8y ago
> I think we agree more than we disagree. I think so. > However, if you're making a program to solve a problem which is novel to you, it makes more sense to write the tests after you have a solution, since it's likely that your first few attempts to solve the problem will have to be heavily refactored before you have something that works in the way that you want. I slightly disagree. I am happy to put down my purity hammer and spike away happily for a while until I feel I understand the problem well enough. Sometimes long enough to call it a prototype. Then I go back and TDD my way back. The mix, as you note, varies by project. I work in R&D. Some work is more Research, some is more Development. But ultimately some of my work is meant to improve someone's life. One of the ways I satisfy myself that I did a workable job is the tests, and for me at least, writing the tests first achieves that end more effectively. Incremental test-last development works about as well in the small studies as test-first, IIRC. My suspicion is that a non-zero part of the benefit of TDD is that it disciplines you to write a lot of tests. It's a second-order effect that delivers the first-order value.

jacques_chester 8y ago

> I think we agree more than we disagree. I think so. > However, if you're making a program to solve a problem which is novel to you, it makes more sense to write the tests after you have a solution, since it's likely that your first few attempts to solve the problem will have to be heavily refactored before you have something that works in the way that you want. I slightly disagree. I am happy to put down my purity hammer and spike away happily for a while until I feel I understand the problem well enough. Sometimes long enough to call it a prototype. Then I go back and TDD my way back. The mix, as you note, varies by project. I work in R&D. Some work is more Research, some is more Development. But ultimately some of my work is meant to improve someone's life. One of the ways I satisfy myself that I did a workable job is the tests, and for me at least, writing the tests first achieves that end more effectively. Incremental test-last development works about as well in the small studies as test-first, IIRC. My suspicion is that a non-zero part of the benefit of TDD is that it disciplines you to write a lot of tests. It's a second-order effect that delivers the first-order value.