Hacker News Reader

Comment by JoeNr76 | Hacker News Reader

I stopped reading right here:

"Considering the factors mentioned above, we can reason that unit tests are only useful to verify pure business logic inside of a given function."

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

A unit test should test "a unit of functionality" not just a method or a class. Your unit tests also shouldn't be coupled to the implementation of your unit of functionality. If you are making classes or methods public because you want to unit test them, you're doing it wrong.

The exception is maybe those tests you are writing while you're doing the coding. But you don't have to keep them around as they are.

View on HN

> I stopped reading right here:

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.

That person never wrote portable code. I wouldn't envy anyone maintaining or refactoring it to support more platforms.

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.

If you are making classes or methods public because you want to unit test them, you're doing it wrong.

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.

That your public function calls private functions is an implementation detail. It does not matter, test the public function. Subsequently that tests the private functions for all relevant input.

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.

This seems obviously correct to me and it's still not appreciated by many developer teams.

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.

Your expecting too much detail from your tests. As consequence your probably over-specifying them as well. Test through your public interface.

> 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.

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.

I just try to be practical and make them protected so they can be called from the test class which lives in the same package. Perhaps adding a @VisibleOnlyForTesting annotation.

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.

As others have said: you need to think about your functionality as a public API. How the API works under the hood shouldn't affect your tests.

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.

> 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.

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.

IMHO the purpose of unit tests is to ensure the code is correct and allow you to safely refactor and introduce new functionality without breaking existing behavior. The purpose is not to pinpoint the exact line where the bug is, if a test fails.

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.

That's a sign that you're burrying too much functionality to make testing reasonable. It's a sign that you should start splitting that out to more generic functions.

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.

> "Considering the factors mentioned above, we can reason that unit tests are only useful to verify pure business logic inside of a given function."

> 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.

> 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.

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

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

> stopped reading

> it makes the rest of the blogpost also not true

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

Wild speculation with a sprinkle of logic (garbage assumptions lead to garbage conclusions)

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.

It reaks of the same arguement that DHH made about "i hate unit tests because I'm testing getters and setters" (From DHH's point.. yes it's tedious and unit tests on getters/setters are low signal.. but that's a defect in the langauge not with testing)

Reply on news.ycombinator.com