2 ms·

This is a great post. I feel the same on many topics. > I was never a huge TDD believer and I’m not one today. I'll never forget this savage takedown of TDD

by throwaway2037 3y ago

This is a great post. I feel the same on many topics. > I was never a huge TDD believer and I’m not one today. I'll never forget this savage takedown of TDD by Cedric Beust: https://www.beust.com/weblog/the-pitfalls-of-test-driven-development/ https://www.beust.com/weblog/the-pitfalls-of-test-driven-dev... The best rebuttal to TDD that I ever heard from a developer that I respected: "I don't care if you use TDD or whatever. When you commit code, tests need to be included." That's it. And yet, the TDD evangelicals are like the vegans of diet or calisthenicians of fitness -- always annoying, no matter what they say. (Side note: I was a vegan for many years, and I still thought the loud ones were annoying!) > write it twice This is what I hate so much about unit tests -- you chisel the statue once from stone, then, by writing unit tests, you essentially chisel the inverse to fit your new statue. So exhausting.

xlii 3y ago
And yet this is one of the best methods knows to man (See double entry accounting which is used with great success in finance for hundreds of years). An interesting approach I’ve seen was - instead of writing tests - describing step by step scenario for fellow engineer to run on review. When it broke it was due to implicit assumptions or unclear instructions. I believe it was right solution as system input was triple digits of free form documents versus hundreds of configurations and rulesets. I couldn’t imagine dataset for those. Effect was more concise, stable test suite and a rather boring system.
WesolyKubeczek 3y ago
I use TDD in two cases: 1) when I develop something very new to me and learn as I go. I build tests as guardrails, then move along them, fix code, fix tests, fix my assumptions. Usually it lets me move faster and be more confident about what I'm doing. 2) there's a bug reported. I write a test that reproduces the bug first, and iterate on a fix. Helps to go fast immensely. All other cases, I have the same feelings as Thorsten a lot of the time.

xlii 3y ago

And yet this is one of the best methods knows to man (See double entry accounting which is used with great success in finance for hundreds of years). An interesting approach I’ve seen was - instead of writing tests - describing step by step scenario for fellow engineer to run on review. When it broke it was due to implicit assumptions or unclear instructions. I believe it was right solution as system input was triple digits of free form documents versus hundreds of configurations and rulesets. I couldn’t imagine dataset for those. Effect was more concise, stable test suite and a rather boring system.

WesolyKubeczek 3y ago

I use TDD in two cases: 1) when I develop something very new to me and learn as I go. I build tests as guardrails, then move along them, fix code, fix tests, fix my assumptions. Usually it lets me move faster and be more confident about what I'm doing. 2) there's a bug reported. I write a test that reproduces the bug first, and iterate on a fix. Helps to go fast immensely. All other cases, I have the same feelings as Thorsten a lot of the time.