I have found Unit Tests and TDD in general [...]

not the same thing - you can do TDD with end-to-end tests. It takes longer, it's more BDD, but you can do it. Anyway...

[...] compared to automated Functional tests based on requirements.

The assumption being that the unit test aren't based on requirements? I think if you read the author you'd see that what you think of as a functional test is more like a unit test for him: testing the 'business' (i.e. the really important what it ought to do) logic of a program. Not the incidental, one-test-per-function/method/object/class craziness.

As to Coplien's diatribe, it's pretty much 'bad tests are bad' and that coverage won't save you in the end. Well, nobody said it would. If you're testing at the wrong level 100% code coverage is actively harmful. If your test suite is more complicated than your code, you're doing it wrong. Doesn't mean you stop doing it and start driving everything through a web browser and testing your HTML got written right.

more assertions in code.

Doesn't that just give you runtime errors to tell you when things are wrong? You actually do this? I thought it went the way of the goto...

 

Some good points there. Thanks. Although, in years of seeing huge amounts of TDD and Unit Tests, the amount of new information they give you over end-to-end tests based on requirements is minimal compared to the effort. And I would argue, if your unit tests are not complex, then they simply cannot cover the combinations needed to be of any real value. I have seen some very complex pieces of software succeed without TDD and Unit Testing. Each to their own. :)

 

One more comment, re: assertions.

You may know them as throwing exceptions. Same thing really, checking some condition is valid before proceeding at run time to avoid terrible things happening.

code of conduct - report abuse