3 ms·

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

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.

Chris2048 4y ago
> 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?
- JoeNr76 4y ago
  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.
Ygg2 4y ago
> "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.
- fivea 4y ago
  > 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.
  - Ygg2 4y ago
    > 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.
fivea 4y ago
> 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.
- AstralStorm 4y ago
  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.
dagw 4y ago
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.
- JoeNr76 4y ago
  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.
- onli 4y ago
  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.
  - oxff 4y ago
    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.
- UK-AL 4y ago
  Your expecting too much detail from your tests. As consequence your probably over-specifying them as well. Test through your public interface.
- teddyh 4y ago
  > 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.
monksy 4y ago
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)

Chris2048 4y ago

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

JoeNr76 4y ago
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.

Ygg2 4y ago

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

fivea 4y ago
> 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.
- Ygg2 4y ago
  > 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.

fivea 4y ago

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

AstralStorm 4y ago
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.

dagw 4y ago

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.

JoeNr76 4y ago
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.
onli 4y ago
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.
- oxff 4y ago
  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.
UK-AL 4y ago
Your expecting too much detail from your tests. As consequence your probably over-specifying them as well. Test through your public interface.
teddyh 4y ago
> 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.

monksy 4y ago

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)