3 ms·

Nobody should stick to any dogma past the honeymoon period. The point of a dogma is to get you into the behavior space that you will learn how to do something w

Nobody should stick to any dogma past the honeymoon period. The point of a dogma is to get you into the behavior space that you will learn how to do something well. It's like using a recipe in a cookbook. Once I had enough practice making scrambled eggs, I didn't need a recipe anymore. I learned TDD ~20 years ago from Beck's "TDD by Example" book. For me it's far more than "just another tool". I'll certainly do exploratory work with throwaway code. And in the early stages of something, I might be a bit slack. But the lesson over and over for me is that if I don't get to significant test coverage soon, I end up wasting a lot of time on bugs. And TDD is the easiest way to get to test coverage. Test-first ends up feeling like a set of small successes with the red-great-refactor loop. With test-after, going back and adding tests feels more like drudgery, and I'm less likely to have written the code in a testable way. So TDD is not dogma for me, just the inevitable place I end up if I want to maximize the amount of time getting things done while working on a non-trivial codebase.

wpietri 5y ago
That said, I totally agree that Martin is a salesman. I knew him in the early days of the Agile movement and he did a lot of good then. But he's become consistently more strident, more dogmatic, more unpleasant. It's sad to see, really.
- roguas 5y ago
  I think it's the archetypical story of you either die a hero... People find new ways to cope with complex problems, they soon become bound to those new ways.
  - wpietri 5y ago
    No, I think he's become the villain for unrelated reasons. A lot of the early Agile people are still out there doing good work. More than I'd expect, honestly; the people who are attracted to a wild, early-stage idea are a very mixed bag.
nightski 5y ago
I had a similar trajectory but opposite experience. I felt like after doing heavy TDD and even FP after a while TDD felt more and more like a waste of time. I find that I naturally think and design in a test driven perspective without actually writing the tests due to many years of experience. 1.) I'd much rather lean on the type system to prove things than automated tests if possible. But of course depending on the language that often isn't possible. 2.) I find that only a small fraction of my code really benefits from automated testing. This is the logic/calculation parts of the code. The rest is slinging IO and SQL queries which all ends up being mocked out anyways and the tests just become secondary implementations of the original code.
- wpietri 5y ago
  I am all for people finding the minimum sufficient amount of testing to get the quality they want. And I agree that if one's project is amenable to strong typing, that's a better place to put some concerns than unit tests. I also agree that people newer to testing things tend to ritualistically over-test in ways that feel complete to them but don't really advance quality. That said, my solution to that isn't to not test, it's to start with broad, high-level tests that make sure the whole thing works together. Then I add automated tests whenever I get bugs, whenever I find myself manually testing something to make sure it works, and whenever tests would have documentary value. For those edge-of-system things, if you haven't tried it you might consider abstracting them out. E.g., with SQL persistence I might end up with an abstract Store and implementations of InMemoryStore and DatabaseStore. The fast version of the tests uses the former and I run it all the time when testing. The slow version uses the latter and it gets run less often. That can get rid of a lot of essentially duplicative testing while still giving a fast feedback loop.

wpietri 5y ago

That said, I totally agree that Martin is a salesman. I knew him in the early days of the Agile movement and he did a lot of good then. But he's become consistently more strident, more dogmatic, more unpleasant. It's sad to see, really.

roguas 5y ago
I think it's the archetypical story of you either die a hero... People find new ways to cope with complex problems, they soon become bound to those new ways.
- wpietri 5y ago
  No, I think he's become the villain for unrelated reasons. A lot of the early Agile people are still out there doing good work. More than I'd expect, honestly; the people who are attracted to a wild, early-stage idea are a very mixed bag.

nightski 5y ago

I had a similar trajectory but opposite experience. I felt like after doing heavy TDD and even FP after a while TDD felt more and more like a waste of time. I find that I naturally think and design in a test driven perspective without actually writing the tests due to many years of experience. 1.) I'd much rather lean on the type system to prove things than automated tests if possible. But of course depending on the language that often isn't possible. 2.) I find that only a small fraction of my code really benefits from automated testing. This is the logic/calculation parts of the code. The rest is slinging IO and SQL queries which all ends up being mocked out anyways and the tests just become secondary implementations of the original code.

wpietri 5y ago
I am all for people finding the minimum sufficient amount of testing to get the quality they want. And I agree that if one's project is amenable to strong typing, that's a better place to put some concerns than unit tests. I also agree that people newer to testing things tend to ritualistically over-test in ways that feel complete to them but don't really advance quality. That said, my solution to that isn't to not test, it's to start with broad, high-level tests that make sure the whole thing works together. Then I add automated tests whenever I get bugs, whenever I find myself manually testing something to make sure it works, and whenever tests would have documentary value. For those edge-of-system things, if you haven't tried it you might consider abstracting them out. E.g., with SQL persistence I might end up with an abstract Store and implementations of InMemoryStore and DatabaseStore. The fast version of the tests uses the former and I run it all the time when testing. The slow version uses the latter and it gets run less often. That can get rid of a lot of essentially duplicative testing while still giving a fast feedback loop.