Me too. The author shows a deep misunderstanding and even obliviousness to testing, particularly from a practical point of view, that takes any credibility from any argument listed in the article.

It's even perplexing how the best example the author could come up with was this absurd chain of strawmen that a) it's impossible to test code that uses instances of HttpClient, b) dependencies used in dependency injection "serve no practical purpose other than making unit testing possible."

There are plenty of people talking about unit tests. This article is not one of which justifies any click.

Main reasons to have dependency injection is to have properly runtime switchable code with less shared state. That it makes testing easier is a side effect.

I've heard this a lot, but how do I test private methods right? If my public method just calls 8 private methods (which each call out to a bunch of other private methods), how to I test to make sure all those private methods do what I want them to do so that I know which one is broken when my public method breaks.

There was recently a submission here on HN that talked about this and different perspectives on that topic. It's not a universally shared opinion, surprisingly.

Then there's the world of behavior / property / invariant -based testing which slims down your tests to essentially data generation and testing observable behavior which seems like magic to people still.

You don’t. You test only the public API. This way, you can refactor the public method to your heart’s content without any tests breaking.

The reality is that these private functions are building blocks that can be easier to test. If you only test the public methods, testing gets a lot more challenging and the methods are more difficult to test and the tests classes get a lot of more complicated. You end up creating more mocks or other doubles and bending backwards.

Others have pointed out that you test only public methods. The thing I'd add to that: Having large classes is a code smell. If your class is big, it is probably several classes in one. Break it up accordingly. Some of your private methods in the big class will become public methods in the small class.

What you describe is white-box testing, where the test is coupled to implementation details of a class. This gives you more fine-grained reporting in case of an error but it makes it impossible to refactor the code safely. So I don't think that is a worthy trade-off.

If you often have hard-to-locate bugs in particular large component, the solution is probably to refactor into smaller more loosely-coupled components with well-defined interfaces.

Scala is great about making these functions generic. Java has an issue with this where lots of things are easy to get burried but hard to reason about pulling them out.

So how do you test private methods? You don't, with the exception of testing during development, but those aren supposed to be kept around.

> That just isn't true and it makes the rest of the blogpost also not true.

It's not? Writing unit test is all about minimizing side effects and interaction with other systems.

Not really. Writing unit tests is all about verifying behavior from combinations of inputs, and side effects are inputs as well.

You can write unit tests that inject delays and timeouts and retries and throw exceptions under specific circumstances.

Well, except it's not. If you use a side effect, you have to account for it in some way via mocks or whatever.

> it makes the rest of the blogpost also not true

what do you know of the rest of the blogpost if you stopped reading?

HOWEVER, I have skimmed through it by now and the last paragraph is actually quite good. It takes a while to get there and the chosen examples aren't great, though.