[crazygringo]

> One of the worst pieces of advice that I ever received was that every function should be unit tested.

Obviously not every function should be -- many are so obvious and straightforward that there's nothing to test -- but every function that does anything vaguely "algorithmic" should be. Unit testing is really important for catching logic errors.

> Instead, write higher level tests close to the client/user facing behaviour that actually give you protection against breaking things unintentionally

Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both.

In fact, sometimes you even need to split up functions smaller than they otherwise would be, just so you can test an inner logic portion independently.

[RHSeeger]

> Yes, these are good. But they're a different kind of test

I've had this exact same discussion with people before. The same people that say "unit tests are worthless because the implementation could change, then the test gets thrown away". Honestly, it drives me bonkers because that entire argument makes no sense to me.

[crazygringo]

Seriously. Yes, it goes without saying that if you throw out the old implementation and write a new one, you throw out the old tests and write new ones as necessary.

It's as banal as saying that when you change a function definition, you have to go change all the places that call it. What do you expect?

[1dom]

> Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both.

Why do you need both?

Some software is so small and simple that it's possible to write a high level running/integration test that covers all the practical correctness tests that application might need too.

You can say "yeah, but they'd be better if they had unit test" but that's the point being made: eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value, and even make the code harder and slower to maintain.

[crazygringo]

> Why do you need both?

Sure, you don't need unit tests if you don't need unit tests because a program really is that simple. But that's an exception for tiny programs/modules, not the rule.

> eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value

I explicitly said unit tests are for algorithmic code that can have logic errors. Obviously, if you've written tests for all those, you don't need any more.

> and even make the code harder and slower to maintain.

But you can trust the code is correct. Obviously this is the tradeoff, and for anything serious it's the right tradeoff.

You seem to be arguing against tests generally except for the most superficial ones. That's a recipe for buggy and often hard-to-understand, underspecified code.

[1dom]

I'm arguing for appropriate, practical levels of testing, which could sometimes mean not all code has both unit and integration tests. I think that's the point the article is making: you don't always need both, focus on real world value.