ArtemGovorov
commented
3 years ago Thanks for sharing the repo.
Code coverage works as expected in this case. Wallaby collect branch coverage, so coverage indicators show if certain code branch had been executed or not. Curried functions (that are expressed in the code as simple expression with no coverable/conditional branches) are not something special to Wallaby (or any code coverage tools).
Let's consider your example:
For the purposes of code coverage collection matter, it can be simplified as follows:
...
const a = b(c.d([...]), e.f(_ => g.h(_))), i.j(k.l));
...or even further:
...
const a = b(c(d), f(_ => h(_))), j(k));
...There are only 2 code regions that matter here in terms of code coverage (that may or may not be executed and thus may change the code coverage):
- variable declaration statement:
const a = ... - arrow function body:
_ => h(_)
All other expressions in the b function parameter list are always executed (to pass those arguments to the b function), so it doesn't make sense to treat them as separate coverable code regions/branches.
Semantics of the executed code (ie. the fact that some of the parameters may or may not be functions that may be used somewhere later in the code) are simply impossible to consider for the code coverage purposes.
The behaviour described above is not specific to Wallaby, Jest/Istanbul coverage works the same way:
Hope it makes sense. Let me know if you have any question re the coverage logic described above.
schickling
Issue description or question
Seems like curried functions are not picked up for code coverage detection see here:
Repro: I've forked the fp-ts repo and added a simple test case
test/Applicative.tsto illustrate the problem.https://github.com/schickling-repros/wallaby-coverage-repro-2020-12-21
Wallaby diagnostics report