3 ms·

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

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

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.