4 ms·

Can you elaborate?

by djrtwo 10y ago

Can you elaborate?

problems 10y ago
If you write testable software and actually write the tests, the end result is the same whether you test first or test later. You're designing with testing in mind and creating useful tests either way. It's really a matter of code that lacks tests that's an issue and especially of code which isn't designed with testing in mind. I think they overinterpreted the value of TDD as simply test-first. Test first can be good but it's more a motivational tool and a productivity simulator (yay look at those green checkmarks!) than a real benefit. The end result is identical, this sort of craps on it as a motivational tool too if you consider that only as a factor in development time at least. It'd be interesting to see developer satisfaction included in some way too.
- ams6110 10y ago
  I have always worked in a "test last" mode. That's the way I learned to program. Write some code, test it. When it works, write some more code, test some more. My attempts to work in a TDD style ran up against decades of intgrained habits and I never really found it satisfying or natural.
  - wpietri 10y ago
    It took me a year or so to make the transition. And I think the transition is easier to make in a greenfield or already-TDDed code base. That's not to say that you should try it again; I like TDD a lot myself, but software methods are so interdependent that I think each person has to judge what works best for them.
- wpietri 10y ago
  > If you write testable software and actually write the tests, the end result is the same whether you test first or test later. This is definitely not my experience. As Kent Beck says, TDD is a design technique. It forces you to always start thinking of the code from the outside of the unit. If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works.
  - zzalpha 10y ago
    If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works. Will you? Are you sure? Do you have data to back your supposition? My contention would be that at the end of the day, the requirements of the interface to support unit testing will result in a very similar set of design choices, whether you write those tests up-front, as-you-go, or after-the-fact. The only difference is that if you write them after-the-fact, you may push some amount of refactoring to the end of the process instead of doing it along the way. But I'll bet you have about as much data as I do to back your beliefs. ;)
    - wpietri 10y ago
      > Do you have data to back your supposition? That's my experience. I started doing TDD more than 10 years ago, and it took me about a year to fully make the switch from test-after to test-first programming. I regularly try experiments with different personal code bases. If you're arguing from personal experience, that your code ends up just the same either way, good for you. But I suspect you're arguing from theory here.
  - problems 10y ago
    Perhaps it depends on how you implement each. If your idea of test last is writing a full large module and then trying to test that all at once, you might wind up with a different result than if you wrote an individual function or two and tried to test only those at once. Getting the testing as close in time to the implementation as possible probably makes a bigger difference than first vs last.
    - wpietri 10y ago
      I definitely agree with that. If there is somebody who actually writes a few units of production code, a few units of test code, and then refactors, then I expect things would be pretty close. However, for me that's a hard set of behaviors to stick to. If I let myself say, "Oh, I'll test that later" I'm likely to get lost in the problem, write bunch of production code, and then say, "Well, it already works, but I guess I'll add some tests." There's no clear stopping point. Test-first programming, on the other hand, is easier for me to stick to. If I don't have a broken test, I write one. If I have made the test pass, it's time to write another test before I write more production code.
- perlpimp 10y ago
  tests can do alot of things, I wish there'd be a more functional name for them, ie. regression stoppers.
zzalpha 10y ago
Well, let me ask you: Why would we assume TDD would improve code quality or development time? If, at the end of the day, the result is the same volume of tests and the same level of overall coverage, the order of activity would seem to make no difference. What would lead you to believe otherwise? The real flaw in both methodologies is that it's the developer checking their own work. I'd make the claim that if you really wanted to do it "right", you'd have a specification, one developer writing tests to the specification, and a different developer writing the code to make the tests pass. Of course, that's probably not workable in practice... make for an interesting experiment, though (and yes, I'm too lazy to search Google, only to discover someone else already came up with the idea).

Can you elaborate?

by djrtwo 10y ago

Can you elaborate?

If you write testable software and actually write the tests, the end result is the same whether you test first or test later. You're designing with testing in mind and creating useful tests either way. It's really a matter of code that lacks tests that's an issue and especially of code which isn't designed with testing in mind. I think they overinterpreted the value of TDD as simply test-first. Test first can be good but it's more a motivational tool and a productivity simulator (yay look at those green checkmarks!) than a real benefit. The end result is identical, this sort of craps on it as a motivational tool too if you consider that only as a factor in development time at least. It'd be interesting to see developer satisfaction included in some way too.

ams6110 10y ago
I have always worked in a "test last" mode. That's the way I learned to program. Write some code, test it. When it works, write some more code, test some more. My attempts to work in a TDD style ran up against decades of intgrained habits and I never really found it satisfying or natural.
- wpietri 10y ago
  It took me a year or so to make the transition. And I think the transition is easier to make in a greenfield or already-TDDed code base. That's not to say that you should try it again; I like TDD a lot myself, but software methods are so interdependent that I think each person has to judge what works best for them.
wpietri 10y ago
> If you write testable software and actually write the tests, the end result is the same whether you test first or test later. This is definitely not my experience. As Kent Beck says, TDD is a design technique. It forces you to always start thinking of the code from the outside of the unit. If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works.
- zzalpha 10y ago
  If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works. Will you? Are you sure? Do you have data to back your supposition? My contention would be that at the end of the day, the requirements of the interface to support unit testing will result in a very similar set of design choices, whether you write those tests up-front, as-you-go, or after-the-fact. The only difference is that if you write them after-the-fact, you may push some amount of refactoring to the end of the process instead of doing it along the way. But I'll bet you have about as much data as I do to back your beliefs. ;)
  - wpietri 10y ago
    > Do you have data to back your supposition? That's my experience. I started doing TDD more than 10 years ago, and it took me about a year to fully make the switch from test-after to test-first programming. I regularly try experiments with different personal code bases. If you're arguing from personal experience, that your code ends up just the same either way, good for you. But I suspect you're arguing from theory here.
- problems 10y ago
  Perhaps it depends on how you implement each. If your idea of test last is writing a full large module and then trying to test that all at once, you might wind up with a different result than if you wrote an individual function or two and tried to test only those at once. Getting the testing as close in time to the implementation as possible probably makes a bigger difference than first vs last.
  - wpietri 10y ago
    I definitely agree with that. If there is somebody who actually writes a few units of production code, a few units of test code, and then refactors, then I expect things would be pretty close. However, for me that's a hard set of behaviors to stick to. If I let myself say, "Oh, I'll test that later" I'm likely to get lost in the problem, write bunch of production code, and then say, "Well, it already works, but I guess I'll add some tests." There's no clear stopping point. Test-first programming, on the other hand, is easier for me to stick to. If I don't have a broken test, I write one. If I have made the test pass, it's time to write another test before I write more production code.
perlpimp 10y ago
tests can do alot of things, I wish there'd be a more functional name for them, ie. regression stoppers.

zzalpha 10y ago

Well, let me ask you: Why would we assume TDD would improve code quality or development time? If, at the end of the day, the result is the same volume of tests and the same level of overall coverage, the order of activity would seem to make no difference. What would lead you to believe otherwise? The real flaw in both methodologies is that it's the developer checking their own work. I'd make the claim that if you really wanted to do it "right", you'd have a specification, one developer writing tests to the specification, and a different developer writing the code to make the tests pass. Of course, that's probably not workable in practice... make for an interesting experiment, though (and yes, I'm too lazy to search Google, only to discover someone else already came up with the idea).