Hacker News Reader

Comment by jmconfuzeus | Hacker News Reader

I noticed that proponents of TDD are mostly consultants who sell TDD courses or seminars.

You rarely see someone who writes production code preach TDD.

Something fishy there...

This is true. There are engineers who practice TDD as well, although quite few in my experience. The code I've seen come out from hardcore TDD is utter crap, because what truly matters is a good design. In fact writing tests first by design produces crappily designed and messy code and by extension crappily designed tests. Hence you end up with crap all over.

> writing a test first by design produces crappily designed and messy code?

So you don’t get a say in the test or the code? It just messes itself up?

Interesting thought, but every evangelist of TDD that I’ve met has nothing to gain other than wanting the code in production to be cheaper to write, more maintainable, proven to work, faster to market, the list goes on. They often care more about the business and the costs involved in software development and are usually pretty selfless.

People who write production code generally have QA teams they yeet the testing burden to.

Said teams absorb a lot of the pain of Soft Devs who don't bother even running their own code.

The "throw shit at the wall and see what sticks" programming technique.

Several years ago I was part of a team of developers in an org that did not have a formal QA process. Code was "just OK" but we shipped working products. At some point we (the management) decided to add a QA step with formal QA Engineers (doing part QA automation and manual QA). As a result Engineers became sloppy and realized they could get "extra time" if they delivered half-assed code that had bugs that were caught by QA. That was painful.

That's fair but let's not pretend QA is even in the same ballpark as tests, QA is about a billion times more useful. First and foremost because they didn't write the code.

I believe strongly that developers make horrible tests because it's a completely different mindset that is not easy to switch between and near impossible if you wrote the code yourself that you are testing. We tend to lean into the "happy path" and don't even consider "outlandish" things a user might do. I have immense respect for a good QA person and I've had the privilege of working with a number of them, some I'd hire in a heartbeat if it were up to me.

I'm not 100% anti-testing but the only testing I've seen produce real results was automated browser testing, and that was only after 2 very large attempts by the development team to do it. Finally we brought in someone whose sole job was the automated browser testing suite. In a very short amount of time he had something working that was producing useful results, something our 2 previous attempts never did. I believe it was in part since he didn't work with or write any of the code, he had no preconceptions, he didn't "think" the way we did since we knew the inner workings. From this and other experiences I think QA and Dev should be 2 seperate groups/teams without overlap (don't have devs do QA, they don't like doing it and they just aren't good at it).

Nah, the best teams don’t need QA.

Caveat - because you bake the QA in. The code itself is already quality assured. Then QA resources can do exploratory testing which does carry a separate value.

No way, this is false. Tons of engineers preach TDD.

Reply on news.ycombinator.com