4 ms·

On the other side: Today I was working with a new library. I wrote a 30 line sample program just to make sure I understood the library semantics, and that it w

On the other side: Today I was working with a new library. I wrote a 30 line sample program just to make sure I understood the library semantics, and that it would at least do what I thought in a situation similar to the actual code base. I called over another developer to sanity check my thinking, and he spent 10 minutes going on how I should have just written tests for it in our codebase instead. He would not take any of these as valid discussion points: * I spent nearly 7 minutes on my sample code, writing tests including the appropriate mocks for our codebase would have taken 70. * I didn't even know we would be moving forward with that library, why start integrating it into our infrastructure? * I'll write tests of our code using the library, when we figure out what the thing we're building actually does. * I would have to write that same sample program before I can even write tests, to know how to use the library. I do know now not to include that guy in my thinking process ever again, if tests aren't perfect, I will lose any time including someone might gain by dealing with his TDD is my holy saviour rants about how I should learn. Worst part: this guy takes days to write "tested" code that still doesn't actually do what it is supposed to.

shasta 14y ago
That guy is an asshole.
- Evbn 14y ago
  Yet is still better in general to solidify your gains into repeatable tests, instead of throwing away all your research. To the GP, yes, the less you write tests, the more your code base rolls up into a giant ball of hair and wax, and you can't investigate the behavior of any part of it without mocking out the rest of it. That is why we say testable code is usable code.
  - btilly 14y ago
    I've been on both sides of this. You do not want to wind up with important code that is not tested. I spent hours today chasing down bugs in code that I wrote over the last month that I would have never known were there if I had not been writing tests. I value tests. But on the other hand there is a valid role for experimenting and trying things out. In that mode you're not writing production ready code - you're throwing stuff together. When you write code in that mode, following a testing mantra is worse than useless. I say worse than useless because the mental energy spent testing gets in the way of experimenting and refactoring. The right way to reconcile those two modes is to write your experimental code, think about it, figure out how you want it written, then once you know how to write it, go back and write it "for real", complete with tests. In fact the carefully tested code that I was writing today is based in large part on ideas that I figured out in a throw away prototype written some time ago, in a different language, that had very little in the way of tests.
andreasklinger 14y ago
You did a spike. It's ok to be untested for discovery. Even in TDD. In pure TDD you would be supposed to throw it away afterwards and redo it clean (with learnings) based on test-first.
- RyanZAG 14y ago
  And that is exactly what is wrong with TDD - the sheer dogma involved in a insane statement like that. Throw out all the code - tests weren't written first! It doesn't seem to matter much that the end result will be the same if you write up some tests for that code, or if you throw the code out, write tests, then just write the same code again. If the tests didn't come first, it's not TDD, and now we can't follow some holy procedure. Pure madness and everything that is wrong with TDD is summed up in that simple statement: "In TDD you would throw it away and redo it".
  - andreasklinger 14y ago
    I am not a TDD advocate. As it tends to be too cost intense in early stage startups. But if you are working on critical parts or products you know will be in use for a longer time it is usually the right approach. To defend why you should throw spike results away in TDD: - Usually during a spike you learn how to use an api/framework. You are focusing on very low level solutions. - You made it work the first time. But now when you do it again you wouldn't do it the same way. You don't redo usually. - Usually the second time the solution is clean and proper strcutured. TDD is very focused around proper software design. And for the areas where you actually need that it is a great tool.
  - dllthomas 14y ago
    In any development, you probably want to throw away your exploratory prototyping - that's not TDD specific. I've seen/heard "write it; throw it away; rewrite it" attributed to Knuth on several occasions, but I'm not finding the original source.
    - pmcelhaney 14y ago
billforsternz 14y ago
I feel your pain. It sounds like your colleague really likes his hammer and now sees all problems as nails. What you were doing was a little experimental probing of a possible line of enquiry. Basically some stuff on which TDD has nothing to say.

shasta 14y ago

That guy is an asshole.

Evbn 14y ago
Yet is still better in general to solidify your gains into repeatable tests, instead of throwing away all your research. To the GP, yes, the less you write tests, the more your code base rolls up into a giant ball of hair and wax, and you can't investigate the behavior of any part of it without mocking out the rest of it. That is why we say testable code is usable code.
- btilly 14y ago
  I've been on both sides of this. You do not want to wind up with important code that is not tested. I spent hours today chasing down bugs in code that I wrote over the last month that I would have never known were there if I had not been writing tests. I value tests. But on the other hand there is a valid role for experimenting and trying things out. In that mode you're not writing production ready code - you're throwing stuff together. When you write code in that mode, following a testing mantra is worse than useless. I say worse than useless because the mental energy spent testing gets in the way of experimenting and refactoring. The right way to reconcile those two modes is to write your experimental code, think about it, figure out how you want it written, then once you know how to write it, go back and write it "for real", complete with tests. In fact the carefully tested code that I was writing today is based in large part on ideas that I figured out in a throw away prototype written some time ago, in a different language, that had very little in the way of tests.

andreasklinger 14y ago

You did a spike. It's ok to be untested for discovery. Even in TDD. In pure TDD you would be supposed to throw it away afterwards and redo it clean (with learnings) based on test-first.

RyanZAG 14y ago
And that is exactly what is wrong with TDD - the sheer dogma involved in a insane statement like that. Throw out all the code - tests weren't written first! It doesn't seem to matter much that the end result will be the same if you write up some tests for that code, or if you throw the code out, write tests, then just write the same code again. If the tests didn't come first, it's not TDD, and now we can't follow some holy procedure. Pure madness and everything that is wrong with TDD is summed up in that simple statement: "In TDD you would throw it away and redo it".
- andreasklinger 14y ago
  I am not a TDD advocate. As it tends to be too cost intense in early stage startups. But if you are working on critical parts or products you know will be in use for a longer time it is usually the right approach. To defend why you should throw spike results away in TDD: - Usually during a spike you learn how to use an api/framework. You are focusing on very low level solutions. - You made it work the first time. But now when you do it again you wouldn't do it the same way. You don't redo usually. - Usually the second time the solution is clean and proper strcutured. TDD is very focused around proper software design. And for the areas where you actually need that it is a great tool.
- dllthomas 14y ago
  In any development, you probably want to throw away your exploratory prototyping - that's not TDD specific. I've seen/heard "write it; throw it away; rewrite it" attributed to Knuth on several occasions, but I'm not finding the original source.
  - pmcelhaney 14y ago

billforsternz 14y ago

I feel your pain. It sounds like your colleague really likes his hammer and now sees all problems as nails. What you were doing was a little experimental probing of a possible line of enquiry. Basically some stuff on which TDD has nothing to say.