Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The day I started believing in unit tests

mental-reverb.com

Post reply on HN
Print view View original

131–140 of 269 posts

Re: The day I started believing in unit tests

#131

Post by corethree »

>It is a little sad to see so many be so dismissive of unit tests.

You're preaching to the choir. The overwhelming majority of people worship unit tests like dogma. There's almost no point in saying the above. It's like saying it's a little sad to see some people who are so dismissive about eating and breathing to stay alive.

Your next part is the one that's interesting. Mocking 80 percent of a system to get unit tests to work. I've seen so much of this from developers who don't even realize the pointlessness of what theyre doing that it's nuts. They worship test so much that they can't see the nuance and the downside.

Take this article. This article is literally presenting evidence for why unit tests are bad. He literally created an error that would not have existed in the first place we're it not for his tests. Yet he has to spin it in such a strange way to make it support the existing dogma of test test test.

Re: The day I started believing in unit tests

#132

Post by throwaway290 »

ska wrote: post #122
throwaway290 wrote: post #118

Earlier quoted context omitted.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

I don't think it is really unresolved. Static languages with sufficiently rich and modifiable type systems avoid a fraction of cases where you may well want a unit test, but it's not the overwhelming majority. Merely static helps too but not all that much. So while there is a reduction, it's a stretch to call it "dramatic".

> I don't think it is really unresolved

Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN.

I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions

Re: The day I started believing in unit tests

#133

Post by randomdata »

throwaway290 wrote: post #118
eddd-ddde wrote: post #112

Earlier quoted context omitted.

I don't think it really matters. Major bugs are not "oh this can be null", major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

A fully evolved type system (e.g. Coq) overlaps with unit testing. But the vast majority of languages people actually use have only partial type systems that require unit tests to stand in where the type system is lacking.

In practice, when you write those tests for where the type system is lacking, you end up also incidentally testing where there is type system coverage, so there likely isn't much for industry to talk about.

Re: The day I started believing in unit tests

#134

Post by troupo »

BurningFrog wrote: post #125
troupo wrote: post #88

Earlier quoted context omitted.

> But in reality, unit testing every single function and method is where the vast majority of the benefit lies. Details really matter. To me, this is actual rookie mentality. You end up testing the same thing multiple times over different lines of code, mocking and providing various sets of testing data... When you could just test specified and/or observable behaviour of your system, and achieve the exactly same resu…

Well, I certainly don't end up doing that. There are many ways of doing things, and I guess we do unit tests differently. > When you could just test specified and/or observable behaviour of your system, and achieve the exactly same result with fewer tests. In my experience, it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. Also, when one of those intermediate…

> Well, I certainly don't end up doing that.

How else are you "unit testing every single function and method"?

> it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface.

If you don't test it, how do you know your system works for that specific behaviour? Just because you've tested every single function and method in isolation doesn't mean they actually work with each other, or produce the responses the way you need them to.

> Also, when one of those intermediate layers changes, you tend to have to rewrite many of those tests.

As you should. Otherwise how do you know that your system still works?

Re: The day I started believing in unit tests

#135

Post by feoren »

6DM wrote: post #106
mrweasel wrote: post #63

It is a little sad to see so many be so dismissive of unit tests. They aren't a universal solution, which seems to be why they are written off in many cases, but they make your life so much easier in so many cases. If you need to mock out 80% of a system to make your unit test work, then yes, it's potentially pointless. In that case I'd argue that you should consider rewriting the code so that it's more testable in i…

I have tried to evangelize unit testing at each company I've worked at and most engineers struggle with two things. The first is getting over the hurdle of trusting that a unit test is good enough, a lot of them only trust an end-to-end test which are usually very brittle. The second reason is, I think, a lot of them don't know how to systematically breakdown test into pieces to validate e.g. I'll do a test for null,…

> I'll do a test for null, then a separate test for something else _assuming_ not null because I've already written a test for that.

Honestly, this pedantry around "unit tests must only test one thing" is counter-productive. Just test as many things as you can at once; it's fine. Most tests should not be failing. Yes, it's slightly less annoying to get 2 failed tests instead of 1 fail that you fix and then another fail from that same test. But it's way more annoying to have to duplicate entire test setups to have one that checks null and another that checks even numbers and another that checks odd numbers and another that checks near-overflow numbers, etc. The latter will result in people resting writing unit tests at all, which is exactly what you've found.

If people are resisting writing unit tests, make writing unit tests easier. Those silly rules do the opposite.

Re: The day I started believing in unit tests

#136

Post by ska »

throwaway290 wrote: post #132
ska wrote: post #122

Earlier quoted context omitted.

I don't think it is really unresolved. Static languages with sufficiently rich and modifiable type systems avoid a fraction of cases where you may well want a unit test, but it's not the overwhelming majority. Merely static helps too but not all that much. So while there is a reduction, it's a stretch to call it "dramatic".

> I don't think it is really unresolved Well, you are currently participating in a thread that discusses this very question so there's that... and such threads are regular on HN. I meant just that. People discuss it. What you want to say is that you have a strong opinion about it, that's OK and still possible with open questions

People discuss lots of things that are pretty well solved; i wouldn't equate "open question" with "lots of discussion".

I guess in this context I mean that the question of static vs. dynamic in unit testing turns out to not be that hard, but the questions like "what is a unit test" and "should we unit test at all" are much muddier. Because people are confused or argumentative about the latter, they tend to pull the former into discussions that don't really have much to do with static vs. dynamic.

Re: The day I started believing in unit tests

#137

Post by feoren »

mrweasel wrote: post #63

It is a little sad to see so many be so dismissive of unit tests. They aren't a universal solution, which seems to be why they are written off in many cases, but they make your life so much easier in so many cases. If you need to mock out 80% of a system to make your unit test work, then yes, it's potentially pointless. In that case I'd argue that you should consider rewriting the code so that it's more testable in i…

For me, the biggest point is that unit tests are not a stand-in for understanding your code. It's like that quote about driving by just crashing into the guardrails all the time. Most unit-testing evangelists sound to me like they're using (or even advocating for) unit testing instead of thinking deeply about their code. Slow down and understand your code.

If you're finding more mistakes by running unit tests than by thinking through and re-reading your code, you're not finding most of your mistakes. Because you're not understanding your own code. How can you even write great unit tests if you don't understand what you're doing?

There are, of course, times when writing the tests first can help you think through a problem -- great! Especially when thinking through how some API would look. But TDD as a methodology gets a hard reject from me.

I certainly reject the argument "unit testing is too hard" -- then your code is bad and you should focus on fixing it. Well-written code is automatically easy to unit test, among 60 other benefits. That's not a reason to avoid unit testing.

Re: The day I started believing in unit tests

#138

Post by zihotki »

mrweasel wrote: post #63

It is a little sad to see so many be so dismissive of unit tests. They aren't a universal solution, which seems to be why they are written off in many cases, but they make your life so much easier in so many cases. If you need to mock out 80% of a system to make your unit test work, then yes, it's potentially pointless. In that case I'd argue that you should consider rewriting the code so that it's more testable in i…

Dismissive of unit tests or TDD? I don't know any peer developer who is dismissive of any form of unit tests. But there are a plenty who are dismissive of TDD.

As for the quality of tests, that's usually a combination of factors and capacity is one of them. At the end if PO's don't see business value in tests, they won't be prioritized.

Re: The day I started believing in unit tests

#139

Post by BurningFrog »

troupo wrote: post #134
BurningFrog wrote: post #125

Earlier quoted context omitted.

Well, I certainly don't end up doing that. There are many ways of doing things, and I guess we do unit tests differently. > When you could just test specified and/or observable behaviour of your system, and achieve the exactly same result with fewer tests. In my experience, it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. Also, when one of those intermediate…

> Well, I certainly don't end up doing that. How else are you "unit testing every single function and method"? > it turns out to be very difficult to test a specific behaviour 5-10 layers deep from an external interface. If you don't test it, how do you know your system works for that specific behaviour? Just because you've tested every single function and method in isolation doesn't mean they actually work with each…

> How else are you "unit testing every single function and method"?

There are many ways to write unit tests, as well as writing code that is easy to test. I don't know how my ways differs from yours, but I don't have much of the problems you mention.

> Otherwise how do you know that your system still works?

We do have some integration test, of course. But it's a small part of the total test suite.

Re: The day I started believing in unit tests

#140

Post by kibwen »

throwaway290 wrote: post #118
eddd-ddde wrote: post #112

Earlier quoted context omitted.

I don't think it really matters. Major bugs are not "oh this can be null", major bugs are "this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

Having static types is like having an automatic, exhaustively comprehensive, efficient unit test generator for the classes of bugs whose units tests are the most boring and annoying to write and maintain. Static types don't prevent you from needing unit tests, they free you up to focus on writing tests that are actually interesting.
Post reply on HN