5 ms·

I'm not the one arguing that the practice is universally valuable. I'm responding to the grandparent's assertion that if you don't understand the problem well e

I'm not the one arguing that the practice is universally valuable. I'm responding to the grandparent's assertion that if you don't understand the problem well enough to write tests, you don't understand the problem well enough to write code. I'm suggesting that that's not always the case: oftentimes when encountering a new problem domain, it's easier to hammer out a crappy solution and watch it fail than it is to deliberately think through test case after test case. Moreover, writing test cases, in my experience, is often a form of fake productivity. It feels good. You're writing code. Hundreds and hundreds of lines of code. But you're not really making any headway on solving the problem.

jacques_chester 8y ago
Sure, I think this is reasonable. Spiking and prototypes are legitimate. I've done both and I expect I'll do both again. I don't necessarily agree about the fake productivity. I don't think of SLOC as the metric of success. In fact, I rarely think about SLOC at all. What matters to me is proving to my own satisfaction that the software works, now and in the future.
- quanticle 8y ago
  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

Sure, I think this is reasonable. Spiking and prototypes are legitimate. I've done both and I expect I'll do both again. I don't necessarily agree about the fake productivity. I don't think of SLOC as the metric of success. In fact, I rarely think about SLOC at all. What matters to me is proving to my own satisfaction that the software works, now and in the future.

quanticle 8y ago
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.