3 ms·

I was never a huge TDD believer and I’m not one today. It’s not about tests but about managing complexity. When working with highly dynamic languages like Java

by xlii 3y ago

I was never a huge TDD believer and I’m not one today. It’s not about tests but about managing complexity. When working with highly dynamic languages like JavaScript, Python, Ruby (at least couple years ago) tests were the only tools we had to handle it. Today some of the most common issues are caught by popular static typed languages (Rust, TypeScript). There are some very smart tools like prop tests and if someone is really deep into modeling it’s also possible to test concepts with TLA+ (fun if you need to explore infinite possibilities of reality bending scenarios). Also qualities of certain languages also make code easier and stabler in domains - e.g. Erlang/Elixir, Clojure or Haskell (and there are much more but those are in my monkey zone). But in the end for me testing is just that: Managing ever growing complexity. And since tracking and maintaining change due to distributed development effort is hard the smallest common denominator I know is… write it twice.

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.

by xlii 3y ago

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.