3 ms·

> If a coding style turns out to be great in theory but not practice, let’s keep the parts that work and toss the rest. My convoluted point is: There are lots o

by shakna 7y ago

> If a coding style turns out to be great in theory but not practice, let’s keep the parts that work and toss the rest. My convoluted point is: There are lots of ways to code, we need to stop holding any one of them up as the “best” way. I think this is the crux of what the authour is trying to say. Not necessarily a criticism of TDD, but rather a criticism of holding to a particular belief no matter the circumstances. Of being inflexible.

hnlmorg 7y ago
I don't disagree with being flexible when needed but the counterargument is that flexibility can sometimes be used as an argument for corner cutting. For example when you start to make a few exceptions for TDD it then becomes easier to make more exceptions; if you're not careful you can quickly end up in a situation where your rational is "we don't have time to write tests" or worse yet "can't be bothered to". The point of methodologies like TDD is they force people to follow the best practices even when it's easier not to simply by mandating a standard process.
- AstralStorm 7y ago
  We start with hard "every module must have an end-to-end test" generally. This is a good level. Add tests as needed for debugging issues. Lately I've hit some joker boss who thinks TDD can be done without automated tests. :( The tests are semi manual (scripted), relatively slow to execute and a development bottleneck as the test machines are few. Some other jokers devs ignored even this limited testing and obvious breakage results.
- shakna 7y ago
  > The point of methodologies like TDD is they force people to follow the best practices even when it's easier not to simply by mandating a standard process. I don't disagree with that, and I don't think the authour disagrees with that. It's when the mandated process interferes with working in the actual world. A better test-pipeline in the article's example might be, "We don't merge without full test coverage of changes" rather than "We must have a test before we've explored how a spec should look". If the standard makes the real world overly difficult, then it will cause people to try and cut corners. It makes the developer seek to do the wrong thing. There's nothing inherently wrong with TDD or a bunch of other processes. There is a problem if you're pushing yourself into a corner where you find yourself fighting the process rather than solving the task that needs solving.
  - hnlmorg 7y ago
    > A better test-pipeline in the article's example might be, "We don't merge without full test coverage of changes" rather than "We must have a test before we've explored how a spec should look". This is very much the rule I prefer to enforce as well. Though I do really like the TDD approach when there are defined specifications or refactoring happens. In those situations it can sometimes even speed up development because once the tests are in place you then have a tighter "write, test, repeat" cycle. However I do still agree with all the points you've raised.

by shakna 7y ago

hnlmorg 7y ago

I don't disagree with being flexible when needed but the counterargument is that flexibility can sometimes be used as an argument for corner cutting. For example when you start to make a few exceptions for TDD it then becomes easier to make more exceptions; if you're not careful you can quickly end up in a situation where your rational is "we don't have time to write tests" or worse yet "can't be bothered to". The point of methodologies like TDD is they force people to follow the best practices even when it's easier not to simply by mandating a standard process.

AstralStorm 7y ago
We start with hard "every module must have an end-to-end test" generally. This is a good level. Add tests as needed for debugging issues. Lately I've hit some joker boss who thinks TDD can be done without automated tests. :( The tests are semi manual (scripted), relatively slow to execute and a development bottleneck as the test machines are few. Some other jokers devs ignored even this limited testing and obvious breakage results.
shakna 7y ago
> The point of methodologies like TDD is they force people to follow the best practices even when it's easier not to simply by mandating a standard process. I don't disagree with that, and I don't think the authour disagrees with that. It's when the mandated process interferes with working in the actual world. A better test-pipeline in the article's example might be, "We don't merge without full test coverage of changes" rather than "We must have a test before we've explored how a spec should look". If the standard makes the real world overly difficult, then it will cause people to try and cut corners. It makes the developer seek to do the wrong thing. There's nothing inherently wrong with TDD or a bunch of other processes. There is a problem if you're pushing yourself into a corner where you find yourself fighting the process rather than solving the task that needs solving.
- hnlmorg 7y ago
  > A better test-pipeline in the article's example might be, "We don't merge without full test coverage of changes" rather than "We must have a test before we've explored how a spec should look". This is very much the rule I prefer to enforce as well. Though I do really like the TDD approach when there are defined specifications or refactoring happens. In those situations it can sometimes even speed up development because once the tests are in place you then have a tighter "write, test, repeat" cycle. However I do still agree with all the points you've raised.