Discussion on: Unit testing frontend code is (probably) useless

[Thomas Hansen]

This may be a misunderstanding; coverage is measured in lines of code covered directly by tests. You can't get a 100% coverage without testing private methods/functions directly

Rubbish. Coverage implies paths of code executed as a consequence of executing your unit tests. Below for instance is a snippet of code

if (someArg) {
   doFoo();
} else {
   doBar();
}

If all my tests for some reasons are entering the above code with someArg always being true, the code inside my else will never execute, and my coverage becomes 50%. If I create a test that passes in false for some reasons, the else will execute and coverage will increase to 100%.

Whether or not the above snippet of code is part of a private method or a public method is irrelevant. You can easily have 100% "coverage" of your code, with thousands of private methods, and never "directly" execute your private methods. If you disagree with the statement in the former sentence, you've got a completely unique definition of "coverage" that I'm certain 99.99999% of all software developers world wide would disagree with you in regards to ...

Edit - Below is coverage of 4 random projects from Magic. As you can see, they've clearly got 100% coverage, even though all projects (obviously) have private methods ...

[JoelBonetR 🥇]

Aha! That's the point I wanted to reach

The problem is, code coverage is a remarkably dumb metric.
In essence, it assumes any test is a good test. It makes no attempt to assess whether you have tested for every scenario.
As a developer, it can be very tempting to assume that good code coverage equates to good testing.

Let’s use a simple example to show what can go wrong.

const product = (a, b) => a * b;

assert product(1, 1) === 1;

Clearly, in the above example, the test achieves 100% code coverage.
However, it isn’t a very good test. For instance, if the operator in product() was changed to divide, the test would still pass! Yet, you have been lulled into a false sense of security because you have 100% code coverage and all your tests pass.

Still, this is better than no tests at all (if the operator changes to sum or subtract it will fail) plus a regression test can simply add an assertion that product(2,3) equals 6 and we should be good from now on.

And that's independent from the context the code resides in either be backend or frontend.
Because following that logic plus the mentioned in the post, if you've a backend that serves a frontend (BFF) why to test the backend in first place then? Simply test the frontend and you'll test the entire backend as well 😁

[Thomas Hansen]

Not only is coverage a good measurement of unit test quality, but it is also the only measure stick we've got. Is it perfect? No. Is your snippet an example of a test where it misses things? Yes. But it's still for all practical concerns the only measurement we've got to (statically) analyse unit test "quality". You still need to bring your brain to the party as you write unit tests. The best example of that would be your own code, that multiples 1 with 1. If one of my developers did that in code, and told me "I implemented 100% coverage", I would chase the guy out of the building with a stick when I realised what he or she had done ...

[JoelBonetR 🥇]

Hahahaha 😂 I imagined it and was funny.

Just pointing out that coverage measures test quantity and not quality even it's bringed over the table when talking about code quality. It it would be a test quality measure, a 100% code coverage codebase won't need regressions and we all know that's not true.

That was a dumb example but I've found things not much cleaver than that tbh 😅

[Thomas Hansen]

coverage measures test quantity and not quality

True, but one speaks about the other, at least to some extent ...

That was a dumb example but I've found things not much cleaver than that tbh

^_^

[JoelBonetR 🥇]

Agree