4 ms·

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 coul

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/
    - AlphaSite 8y ago
      It’s not that the tests fail, so much as they become misleading. They still pass, but they pass because their assumptions are the programs assumptions, but their assumptions are wrong.

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/
  - AlphaSite 8y ago
    It’s not that the tests fail, so much as they become misleading. They still pass, but they pass because their assumptions are the programs assumptions, but their assumptions are wrong.