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

[Thomas Hansen]

You don't have unit tests coverage but code coverage, and having a 100% is ridiculous even for TDD.

I stand corrected. However, as to 100% code coverage, for most applications this is ridiculous, yes. However, we don't deliver "applications" we deliver libraries, frameworks, and tools for others to build applications on top of. Implying even changing a single property, name, or (sigh!) type of exception thrown given a specific error condition, might in theory break thousands of third party apps, we have no access to, and/or ability to test.

When you write code intended for other developers to integrate into their own code, having 100% is neither abnormal, nor unusual. If you create end user apps, it might be ridiculous, and I don't recommend it - However, we're not delivering "end user apps".

you test public functions/methods, not private ones because there's no sense on it.

If you've got private methods with no possible call path through public methods, you've got garbage code, and you need to apply "SHIFT+DELETE refactoring" ...

As the the rest of your comment, its initial parts, most of it are examples of things that is either literally impossible to test (CSS changes), and/or thing you should not test due to reliance upon networking, or other types of IO (database reliance), etc ...

I'll give you one point though, which is code coverage. The rest of your comment is for the most parts plain wrong ...

[JoelBonetR 🥇]

Even you're working on a lib, framework or "tool", you'll have the code logically splitted in this two categories. The public interface (that customers/clients use) is necessarily using the entire private codebase (implementation details) on a way or another, so testing the public one you test indirectly the private one as well.

Testing your private methods/functions directly is still overtesting.

Oh and... Yes, there are ways to test styles applied to any element and to ensure they match the expected. Ypu can also do that for different states (hover, focus...) So you can cover any use case with UI tests.

Unused code simply doesn't fit here and you've different tools to find that: the IDE itself, plugins, tools in the CI pipeline... even a linter can bring an error on that if you configure it properly.

[Thomas Hansen]

The public interface (that customers/clients use) is necessarily using the entire private codebase (implementation details) on a way or another, so testing the public one you test indirectly the private one as well.

Yes, but you said 100% coverage was overkill. I gave you a case where it's not overkill.

Testing your private methods/functions directly is still overtesting.

I never said anything about testing private methods directly, i said, and I quote myself; "we have 100% coverage on some of our components".

Yes, there are ways to test styles applied to any element and to ensure they match the expected

There are also ways to automate usage by creating macros that opens your browser and "pretends" to be a user. They're all for the most parts ridiculous in nature, since their only result is that they give you false negatives as you change your code, and/or add new features to it. If I change the name of a CSS selector to improve code quality for instance, having a "unit test" (notice the double quotes here) break implies my entire foundation for increasing code quality is basically garbage, and my "unit tests" are no longer helping me, but a ball and chain around my neck, prohibiting me from moving forward with speed to improve my app.

[JoelBonetR 🥇]

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.

Styles testing will fail if you change behaviour, and if you change behaviour it's obvious that you need to update your tests as well.
If your suite fails on selecting an item because you changed some classname maybe what's wrong is the way to select those items 🤷🏻‍♀️

[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