Hacker News Reader

TDD does not mean "small unit tests at the method level in code".

It means you code your test cases before you implement the functionalities. Those tests can (and IMO should) be behavior tests: then you can rip out all your code and replace it with whatever you like, even off-the-shelf software and your test suite will still run.

The excuse of those kind of tests being slow or hard to setup mean only one thing: we have to work on their tooling.

View on HN

I share the same opinion. Its been a long time since I read Kent Beck's book on TDD, but I don't recall him saying TDD = unit tests. When I see people using these as synonyms it feels to me they don't quite understood what TDD means and just jumped into this conclusion of "unit tests that check every method/line of code you write".

Testing behavior from the user perspective should be the goal, these are the kind of tests that bring most value in the long run.

> conclusion of "unit tests that check every method/line of code you write".

I think a way to smell you're too far gone on this way is when you write tests only to get code coverage.

With behavior tests, code coverage should become a tool to show where your dead code is so you can remove it.

Reply on news.ycombinator.com