Hacker News Reader

Comment by nobleach | Hacker News Reader

Eh, I knew this would somehow come back to that Kent C Dodds stuff. I can respect the guy, but his opinion on valuable testing differs from mine and quite a lot of others. His opinion is "the more your tests represent the way your users use your app, the better they are". For E2E tests, yes, absolutely. For unit tests, no... not at all. As a very short example, an E2E test will prove that yes, I did indeed show a button on the screen. A unit test will prove the code that put it there worked. The code can "fail open" for many reasons. (In JavaScript for example, forgetting an `await` keyword can return a truthy value!).

The worst part about it is that he called himself a thought leader, called his approach a "best practice" and had nothing really to back that up. Now people go around repeating it all the time. It's frustrating.

View on HN

The thing that drives me nuts about these threads is that people vastly overestimate their ability to write code that isn't broken. I distrust myself, and therefore I write basic unit tests which validate the code I've written to prove that I haven't screwed up.

Such unit tests are quick to write and don't change frequently because they run against low-level building blocks — so they are not a major maintenance burden. The ROI on this kind of testing is very high.

I don't like being told by Dodds and these other unit-test haters that I shouldn't be doing this. In my experience, organizations suffer much more when developers eschew such tests, being quite naturally overly optimistic about the reliability of their work.

Writing low-level unit tests doesn't prevent you from writing integration or end-to-end tests, and those are important too. I'm not here to devalue higher-level testing, and I'd appreciate it if advocates for higher-level testing likewise didn't go out of their way to devalue unit tests.

> I distrust myself, and therefore I write basic unit tests which validate the code I've written to prove that I haven't screwed up.

This drives me nuts.

You don't trust yourself to write code that isn't broken but you trust yourself to write quality tests that ensure the code isn't broken?

I don't understand this at all. Automated tests are just like any code, they are as prone to mistakes and bugs as anything else

My tests might of course be faulty, but statistically speaking adding some will reduce the number of bugs in the main code that get through. The tests don’t have to be perfect to have a positive impact; in fact my impression is that the lowest-effort tests have an outsized impact and a very high ROI.

Respectfully, I disagree, though maybe we haven’t yet articulated enough details to know exactly where we disagree.

I think underlying Kent’s statement is an observation that is undeniably true. The closer a test is to the actual way the software will be used, the better it is in a number of ways, _all else being equal_. All else is never fully equal, which is why everything is about tradeoffs.

But when a test aligns with how the software will be used, there are a whole bunch of synergies and benefits. Simplicity increases, clarity increases, you start getting multiple payoffs for each bit of effort you invest.

I’m sure people cargo cult it and lose track of the tradeoffs, like anything else, but there’s a solid point under there. And I agree with him, it is valuable enough to be called a “best practice.”

I absolutely appreciate respectful disagreement!

The point I often try to make is just how easy it is to get the right result, for the wrong reasons. (especially in loose languages like JavaScript). It goes from making more scientific proofs to, "I saw what I wanted to see on the screen - I can't exactly say why, but I think it's because my code is sound".

It's the equivalent to, "this new flea killer kills twice as many fleas". "What did you change?" "Four different things", "which one ended up being the thing that actually made it work?", "dunno, but now we're seeing twice as many fleas dead!".

If you have an E2E test that tests the button behavior thoroughly (i.e. not just showing it, but the fact that, when it's clicked, the app state changes accordingly), then you have a test showing that "code that put it there worked".

Like I mentioned:

``` function setButtonState() { const res = this.fetchSomeResult(); // returns an unfulfilled promise if (res) { return true; }

  return false;

} ```

as a unit test would quickly fail when you want it to. An E2E test would pass, but for the wrong reasons. This has nothing to do with app state, and everything to do with not being scientific, and testing all sorts of variable things at once just because, "that's what the user sees".

The E2E test would test the user-observable behavior that hinges on this function returning true or false.

If there's no such observable behavior, then why does it matter?

The appeal to "being scientific" doesn't make much sense to me, either. But if you really want to go there, being scientific is all about app state since that's literally all there is to the app.

That’s not in line with the original definition of unit test. It also sounds like a pointless test using your definition. There is no advocacy for writing pointless tests.

It's pointless if one is just trying to put "points on the board" and see a bunch of green in their console. Knowing what to test is important. Should every function be tested? Probably not. Should every function that has conditional logic be tested? Maybe? I totally get that integration tests have immense value. Where I disagree is that, "the closer your tests are to the way a user would use your app" is a good way to use testing. Functional/Acceptance/E2E tests are but one tool in an aresenal. Telling new software developers to ignore 25 years of history because React components were hard to test in isolation (Enzyme - the package Kent's React Test Library is built to replace) is irresponsible. Telling them that it's "best practice" is disingenuous.

Reply on news.ycombinator.com