5 ms·

I've seen big company devs so overwhelmed by messy production code that any small feature change would require 2 weeks of work. I've seen startup devs who coul

by jfabre 14y ago

I've seen big company devs so overwhelmed by messy production code that any small feature change would require 2 weeks of work. I've seen startup devs who couldn't cope with changing requirements fast enough. There was just too many moving parts at the same time. Hell, I've been one of those devs! Great code is the exception, not the norm. When I learned TDD, it greatly improved the quality of my code. If TDD is a bottleneck for you, maybe you need to learn to touch type. My 2 cents.

Glide 14y ago
The process of learning to TDD well makes a person code better, regardless of actually doing it. TDD is one of the few actual disciplines I know of around coding that can't be just glossed over or faked. One either does or does not. This is doubly true in a pair programming environment. Not using one of the established patterns? One can argue around that. Not doing TDD? Justification usually has to tie with UI in some way.
- mnarayan01 14y ago
  > TDD is one of the few actual disciplines I know of around coding that can't be just glossed over or faked. TDD is trivially easy to fake. Perhaps worse, it's trivially easy to think you're doing it, when you're actually doing nothing constructive.
- philwelch 14y ago
  How do you know whether I wrote the tests first by looking at my code?
  - mattgreenrocks 14y ago
    TDD'd code is generally better designed.
  - jdlshore 14y ago
    The difference is pretty clear in practice. It's much harder to add tests to existing code than it is to TDD it, and it takes a huge amount of self-discipline to go back and add tests to "finished" code. So, without TDD, you end up with a relatively small number of tests that test a lot of things, whereas TDD (done well) creates a large number of small tests, each testing one very focused thing.
    - philwelch 14y ago
      As long as I write the tests roughly the same time as the code, it doesn't really matter which I write first. And I always adopt the practice of writing a large number of small tests regardless. Going back and forth is the important part for me, not necessarily writing the tests first. In any kind of setting with shared code, it shouldn't be a matter of self-discipline, it should be a matter of standards and best practice. You shouldn't be integrating any code without test coverage. This is a standard part of how many projects handle pull requests. If you're only accountable to yourself and writing the tests first is the technique that works for you, I can't criticize but you really don't have much to say to programmers in general, either.
tmoertel 14y ago
What did you do before your learned TDD? Did you write automated tests? To what degree?
- jfabre 14y ago
  I did not know much about automated tests, that's true. One thing I noticed though, is that if you don't write tests before hand, you don't have time to write them later. Your code tends to be harder to test too, so you never really write them (costs too much). To me, it's not just about writing tests though. It's about writing an executable todo-list of your features. Before TDD/BDD, I used to take the time to figure out everything I had to do with their relationships together. Most of the time, it would change during the implementation as I forgot about something important while "designing". Also, I used to implement 2/3 things together because they were related. Now I only create a new test and make it pass, then I refactor if I need to and proceed to the next one. If a new idea comes up I write it down on a piece of paper for a future test. This way, my Work In Progress is always 1, before that it was around 3/4 maybe. The mental overhead is much lower because I can rely on all the other tests I made to ensure I did not break my feature. I'm not advocating pure reliance on TDD, but for 95% of the average developers out there, this is definitely an upgrade.
pnathan 14y ago
I just cranked out a pile of code under pressure with a tight time constraint. I didn't TDD. What I did was codesign my tests and code: I rotated between the test and code so that when I finished a particular function, it was reasonably tested. While not, NOT a TDD approach, it did lead to a much higher code coverage and added a safety net when I had to change it: I knew I could change the code, and if the result was materially affected, I'd know. It did slow me down in the initial writing, but in the revisions, it sped me up, IMO.
- jfabre 14y ago
  I agree with you, but before one can transcend TDD, one has to learn it. The pupil was no longer confused. ;) Seriously, the current status quo most of us live in right now is zero to very few automated tests. That's what I'm arguing against.
  - pnathan 14y ago
    > I agree with you, but before one can transcend TDD, one has to learn it. The pupil was no longer confused. ;) I do not claim trascendence. It's just what worked for me. I've never done TDD at any time in my life. Note, after reading the arguments for it here, I think I will give it a spin.

by jfabre 14y ago

Glide 14y ago

The process of learning to TDD well makes a person code better, regardless of actually doing it. TDD is one of the few actual disciplines I know of around coding that can't be just glossed over or faked. One either does or does not. This is doubly true in a pair programming environment. Not using one of the established patterns? One can argue around that. Not doing TDD? Justification usually has to tie with UI in some way.

mnarayan01 14y ago
> TDD is one of the few actual disciplines I know of around coding that can't be just glossed over or faked. TDD is trivially easy to fake. Perhaps worse, it's trivially easy to think you're doing it, when you're actually doing nothing constructive.
philwelch 14y ago
How do you know whether I wrote the tests first by looking at my code?
- mattgreenrocks 14y ago
  TDD'd code is generally better designed.
- jdlshore 14y ago
  The difference is pretty clear in practice. It's much harder to add tests to existing code than it is to TDD it, and it takes a huge amount of self-discipline to go back and add tests to "finished" code. So, without TDD, you end up with a relatively small number of tests that test a lot of things, whereas TDD (done well) creates a large number of small tests, each testing one very focused thing.
  - philwelch 14y ago
    As long as I write the tests roughly the same time as the code, it doesn't really matter which I write first. And I always adopt the practice of writing a large number of small tests regardless. Going back and forth is the important part for me, not necessarily writing the tests first. In any kind of setting with shared code, it shouldn't be a matter of self-discipline, it should be a matter of standards and best practice. You shouldn't be integrating any code without test coverage. This is a standard part of how many projects handle pull requests. If you're only accountable to yourself and writing the tests first is the technique that works for you, I can't criticize but you really don't have much to say to programmers in general, either.

tmoertel 14y ago

What did you do before your learned TDD? Did you write automated tests? To what degree?

jfabre 14y ago
I did not know much about automated tests, that's true. One thing I noticed though, is that if you don't write tests before hand, you don't have time to write them later. Your code tends to be harder to test too, so you never really write them (costs too much). To me, it's not just about writing tests though. It's about writing an executable todo-list of your features. Before TDD/BDD, I used to take the time to figure out everything I had to do with their relationships together. Most of the time, it would change during the implementation as I forgot about something important while "designing". Also, I used to implement 2/3 things together because they were related. Now I only create a new test and make it pass, then I refactor if I need to and proceed to the next one. If a new idea comes up I write it down on a piece of paper for a future test. This way, my Work In Progress is always 1, before that it was around 3/4 maybe. The mental overhead is much lower because I can rely on all the other tests I made to ensure I did not break my feature. I'm not advocating pure reliance on TDD, but for 95% of the average developers out there, this is definitely an upgrade.

pnathan 14y ago

I just cranked out a pile of code under pressure with a tight time constraint. I didn't TDD. What I did was codesign my tests and code: I rotated between the test and code so that when I finished a particular function, it was reasonably tested. While not, NOT a TDD approach, it did lead to a much higher code coverage and added a safety net when I had to change it: I knew I could change the code, and if the result was materially affected, I'd know. It did slow me down in the initial writing, but in the revisions, it sped me up, IMO.

jfabre 14y ago
I agree with you, but before one can transcend TDD, one has to learn it. The pupil was no longer confused. ;) Seriously, the current status quo most of us live in right now is zero to very few automated tests. That's what I'm arguing against.
- pnathan 14y ago
  > I agree with you, but before one can transcend TDD, one has to learn it. The pupil was no longer confused. ;) I do not claim trascendence. It's just what worked for me. I've never done TDD at any time in my life. Note, after reading the arguments for it here, I think I will give it a spin.