undefined | Better HN

0 pointssidlls5y ago0 comments

I take the opposite view. Code developed with TDD tends to be overly complicated and inefficient, and the test suites themselves are often bizarre labyrinthian hellscapes of mocks, facades, and workarounds. "They just did it wrong, then," you say? That statement ceases to be meaningful when it can applied routinely: it's the norm, and if it's the norm, it's not something "they just did it wrong" applies to.

0 comments

5 comments · 1 top-level

blacktriangle5y ago· 4 in thread

So the way that TDD advocates point out that if your tests are ugly, its a sign your code is ugly. I think this also applies to languages and frameworks as well.

For example, I think of the experience doing TDD in Rails with all its ORM and callback interconectedness to TDD on functional code that is mostly exchanging values between systems. All the stub and mock crap goes away since values become the boundary of the system. Gary Bernhardt has an awesome talk making that exact point.

I'm now of the opinion that if TDD is a struggle, its a sign that your environment has serious underlying flaws.

sidllsOP5y ago

"[I]f your tests are ugly, its a sign your code is ugly" is a bit tautological, and highly subjective besides.

I consider the 50-line function to be "less ugly" than the same function butchered for "testability" into a bog of poor abstractions and single-use smaller functions.

disease5y ago

For me at least, TDD has driven me to look for more functional solutions to problems. It's hard to come up with a more testable piece of code than a pure function that spits out the same output every time for a given input.

Unfortunately this approach tends to be less effective in languages that do not have good support for functional ideas like Java and C#.

blacktriangle5y ago

I agree some TDD advocates are way to big on loc as a metric for testability. Loc is pretty much irrelevant for both testability and readability.

carlmr5y ago

>TDD on functional code that is mostly exchanging values between systems. All the stub and mock crap goes away since values become the boundary of the system.

That's generally why I think functional programming is taking off. It's much easier to reason about input-output of stateless functions. They're much easier to test and develop. They're way easier to understand for the reader, because the reader can understand what's happening in one place, instead of having to look through many different files, creating a complex model of all the inheritance relationships between classes.

j / k navigate · click thread line to collapse