5 ms·

XP (and by inference TDD) is often described this way. But after one has practiced it for a while, it's hard to go back. The way I describe it is this: When m

XP (and by inference TDD) is often described this way. But after one has practiced it for a while, it's hard to go back. The way I describe it is this: When most people start as programmers, they write a big 1000 line file that should completely solve the problem. Then they run it, realize it was very wrong, and spend hours debugging it. As programmers learn, they tend to practice "error driven development": they get an idea what they want to happen, they run the program (usually "hello world" to start), and slowly run, edit, run, edit until it evolves into what they want to see. If you practice 2nd process above, you are one step away from TDD. You are still testing, you are just using manual tests. Once you learn to automate those tests easily, why wouldn't you TDD?

lgunsch 8y ago
I've done TDD for years now, and see how my peers do development (non-TDD), and I would definitely agree.
goostavos 8y ago
Is it at all possible that different people like different things, or maybe think differently, or perhaps find different workflows to be productive? If you could buy any of those as anything less than totally preposterous, then you may be able to make the next jump to considering why people like a development practice that differs from the one your prefer. I like tests as more of a 'checkpoint' thing, myself. To each their own. Also, I spend most of my time in a REPL, which I suppose is pretty close to what people tend to get from a TDD kind of loop.
- jacques_chester 8y ago
  > Is it at all possible that different people like different things, or maybe think differently, or perhaps find different workflows to be productive? Yes. But I don't think that's entirely down to innate or inborn characteristics, I think it mostly comes down to experiences. I tried to learn TDD from Beck's book and walked away thinking it was nonsense. Then I went to work at Pivotal Labs and I got a chance to learn it with people whose job consists largely of teaching it. Neither experience is about my largely inherited characteristics. They were experiences. Both were valid in themselves. I have experienced TDD in the good and the bad. I prefer the good, but I know why most folks consider it to be bullshit: that's how they've experienced it.
  - AlphaSite 8y ago
    My experience has been that TDD tends to do a poor job of testing complex systems with complex interactions. If any of the assumptions the tests are based on change (or are incorrect/brittle) then you will silently experience failures. Integration testing is the more valuable side of testing imo but much harder and slower. Also not amiable to TDD in my experience.
    - jacques_chester 8y ago
      I don't think of TDD as being confined to unit tests and I was taught to test from outside in, meaning I'll have acceptance and integration testing as a matter of course.
      - lancerkind 8y ago
        It’s best to have both micro tests (TDD) and macro tests (Acceptance Tests, which if you write acceptance tests first, is referred to as ATDD). TDD refers to micro tests. ATDD is what you should say to communicate clearly what your doing. Saying TDD when you mean ATDD will cause confusion with those who have mature test automation practices. Macro versus micro are important distinctions as they need to be managed differently. Mix those two test inventories together actually causes damage as all your test infrastructure will be slow rather than having a micro test suite that’s faster and run more frequently. Check out Agile Thoughts episodes 1 through 8 for background on this. https://agilenoir.biz/series/agile-thoughts/ https://agilenoir.biz/series/agile-thoughts/
    - lancerkind 8y ago
      None of those tests will silently fail. That’s their point for existing. They complain when the code stops operating as the developer designed it to work. Integration testing is valuable. It just isn’t scalable to the whole code base (because, as you said, it’s slow), that’s why macro tests should be targeted to the parts that can’t be micro tested (10-15%), leaving the bulk of the code to be tested with blazing fast micro tests. Agile Thoughts podcast goes over this during a series on the Testing Pramid, episodes 1 through 8. https://agilenoir.biz/series/agile-thoughts/ https://agilenoir.biz/series/agile-thoughts/
lllr_finger 8y ago
Because the focus should be on correct software and there's a sunk cost fallacy in arguing that you're almost there anyways so why not just buy in to TDD for some purported value. It might help some developers, but it is not a panacea and should not be promoted as such.
- voodootrucker 8y ago
  Sometimes I like to rely on gut-feelings while coding. Ever filled in that user-signup form for the thousandth time? Ever start with nice input: John Doe, 555 fake St Then after the 500th time you are just inputing: aaa abc wsdfg And clicking "sign up"? That is the point you should know in your heart: "I missed writing an automated test somewhere". If you can't relate to the above experience (and have never had your code broken by a coworker), then maybe for some reason you are in a position where you're fine without TDD.
  - crdoconnor 8y ago
    There's also the cost of building the automation to bear in mind https://xkcd.com/1319/ https://xkcd.com/1319/
  - lllr_finger 8y ago
    This implies that a) you can't rely on "gut feeling" without TDD and b) that you don't write tests without TDD. Both of which are incorrect.
deleted 8y ago
[deleted]
PavlovsCat 8y ago
> When most people start as programmers, they write a big 1000 line file that should completely solve the problem. Then they run it, realize it was very wrong, and spend hours debugging it. No, I start line by line, and tend to be thorough. When I start out there is zero complexity, everything I add to it I don't add blindly, with a "rough idea" of what it does. I know exactly what it does. I know where user input and other code ends, and my code begins, at the least, and how I normalize things that cross the threshold. Yes, I'm talking about a solo dev making little things for their own needs, sure. I have the luxury of being as thorough and slow as I want, too. It's not lazyness, the idea of tests actually excited me when I first heard about it. But for example, when I write a particle system, how would I test that? Do I test all combinations of parameters and then compare them with images, which takes a million years? How do I generate the images, with another particle system? How do I test that, in turn? It really does strike me as a "now you have two problems" kind of deal in that situation. In others, the code is just too trivial and unchanging to write a test. What's a "real" application that has good and complete tests? Something like the GIMP, or Blender, or an audio editor, or a complex game? I wouldn't know where to look, and the tests I saw when browsing random github repos often seemed too simple to be useful, often just covering some "token input". But what if your "escape string" function has a bug that kicks in at exactly 15 characters? What if your "get user ID from username" has a bug that ONLY happens when the string "whoops" is in the username? Fuzz everything? Who really does that for applications without serious security implications?
- voodootrucker 8y ago
  I'd love to know how to test graphics and audio programs, frankly. TDD works very well for things with a defined input and output, including: 1. compilers 2. databases 3. all web apps (output is the DOM) In regards to the escape string, if there was a bug at exactly 15 characters, there must be a branch somewhere that isn't being hit, and it should be pretty easy using code coverage reports to find it, and generate the correct input sequence to exercise it. When you get to fuzzing, you're hitting the edge of state-of-the-art. There is good research going on at automating some of that: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
  - 8y ago
lancerkind 8y ago
Brilliantly said!

lgunsch 8y ago

I've done TDD for years now, and see how my peers do development (non-TDD), and I would definitely agree.

goostavos 8y ago

Is it at all possible that different people like different things, or maybe think differently, or perhaps find different workflows to be productive? If you could buy any of those as anything less than totally preposterous, then you may be able to make the next jump to considering why people like a development practice that differs from the one your prefer. I like tests as more of a 'checkpoint' thing, myself. To each their own. Also, I spend most of my time in a REPL, which I suppose is pretty close to what people tend to get from a TDD kind of loop.

jacques_chester 8y ago
> Is it at all possible that different people like different things, or maybe think differently, or perhaps find different workflows to be productive? Yes. But I don't think that's entirely down to innate or inborn characteristics, I think it mostly comes down to experiences. I tried to learn TDD from Beck's book and walked away thinking it was nonsense. Then I went to work at Pivotal Labs and I got a chance to learn it with people whose job consists largely of teaching it. Neither experience is about my largely inherited characteristics. They were experiences. Both were valid in themselves. I have experienced TDD in the good and the bad. I prefer the good, but I know why most folks consider it to be bullshit: that's how they've experienced it.
- AlphaSite 8y ago
  My experience has been that TDD tends to do a poor job of testing complex systems with complex interactions. If any of the assumptions the tests are based on change (or are incorrect/brittle) then you will silently experience failures. Integration testing is the more valuable side of testing imo but much harder and slower. Also not amiable to TDD in my experience.
  - jacques_chester 8y ago
    I don't think of TDD as being confined to unit tests and I was taught to test from outside in, meaning I'll have acceptance and integration testing as a matter of course.
    - lancerkind 8y ago
      It’s best to have both micro tests (TDD) and macro tests (Acceptance Tests, which if you write acceptance tests first, is referred to as ATDD). TDD refers to micro tests. ATDD is what you should say to communicate clearly what your doing. Saying TDD when you mean ATDD will cause confusion with those who have mature test automation practices. Macro versus micro are important distinctions as they need to be managed differently. Mix those two test inventories together actually causes damage as all your test infrastructure will be slow rather than having a micro test suite that’s faster and run more frequently. Check out Agile Thoughts episodes 1 through 8 for background on this. https://agilenoir.biz/series/agile-thoughts/ https://agilenoir.biz/series/agile-thoughts/
  - lancerkind 8y ago
    None of those tests will silently fail. That’s their point for existing. They complain when the code stops operating as the developer designed it to work. Integration testing is valuable. It just isn’t scalable to the whole code base (because, as you said, it’s slow), that’s why macro tests should be targeted to the parts that can’t be micro tested (10-15%), leaving the bulk of the code to be tested with blazing fast micro tests. Agile Thoughts podcast goes over this during a series on the Testing Pramid, episodes 1 through 8. https://agilenoir.biz/series/agile-thoughts/ https://agilenoir.biz/series/agile-thoughts/

lllr_finger 8y ago

Because the focus should be on correct software and there's a sunk cost fallacy in arguing that you're almost there anyways so why not just buy in to TDD for some purported value. It might help some developers, but it is not a panacea and should not be promoted as such.

voodootrucker 8y ago
Sometimes I like to rely on gut-feelings while coding. Ever filled in that user-signup form for the thousandth time? Ever start with nice input: John Doe, 555 fake St Then after the 500th time you are just inputing: aaa abc wsdfg And clicking "sign up"? That is the point you should know in your heart: "I missed writing an automated test somewhere". If you can't relate to the above experience (and have never had your code broken by a coworker), then maybe for some reason you are in a position where you're fine without TDD.
- crdoconnor 8y ago
  There's also the cost of building the automation to bear in mind https://xkcd.com/1319/ https://xkcd.com/1319/
- lllr_finger 8y ago
  This implies that a) you can't rely on "gut feeling" without TDD and b) that you don't write tests without TDD. Both of which are incorrect.

deleted 8y ago

[deleted]

PavlovsCat 8y ago

> When most people start as programmers, they write a big 1000 line file that should completely solve the problem. Then they run it, realize it was very wrong, and spend hours debugging it. No, I start line by line, and tend to be thorough. When I start out there is zero complexity, everything I add to it I don't add blindly, with a "rough idea" of what it does. I know exactly what it does. I know where user input and other code ends, and my code begins, at the least, and how I normalize things that cross the threshold. Yes, I'm talking about a solo dev making little things for their own needs, sure. I have the luxury of being as thorough and slow as I want, too. It's not lazyness, the idea of tests actually excited me when I first heard about it. But for example, when I write a particle system, how would I test that? Do I test all combinations of parameters and then compare them with images, which takes a million years? How do I generate the images, with another particle system? How do I test that, in turn? It really does strike me as a "now you have two problems" kind of deal in that situation. In others, the code is just too trivial and unchanging to write a test. What's a "real" application that has good and complete tests? Something like the GIMP, or Blender, or an audio editor, or a complex game? I wouldn't know where to look, and the tests I saw when browsing random github repos often seemed too simple to be useful, often just covering some "token input". But what if your "escape string" function has a bug that kicks in at exactly 15 characters? What if your "get user ID from username" has a bug that ONLY happens when the string "whoops" is in the username? Fuzz everything? Who really does that for applications without serious security implications?

voodootrucker 8y ago
I'd love to know how to test graphics and audio programs, frankly. TDD works very well for things with a defined input and output, including: 1. compilers 2. databases 3. all web apps (output is the DOM) In regards to the escape string, if there was a bug at exactly 15 characters, there must be a branch somewhere that isn't being hit, and it should be pretty easy using code coverage reports to find it, and generate the correct input sequence to exercise it. When you get to fuzzing, you're hitting the edge of state-of-the-art. There is good research going on at automating some of that: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
- 8y ago

lancerkind 8y ago

Brilliantly said!