Yet another JS code coverage tool that computes statement, line, function and branch coverage with module loader hooks to transparently add coverage when running tests. Supports all JS coverage use cases including unit tests, server side functional tests and browser tests. Built for scale.
Other
8.7k
stars
785
forks
source link
Linear-logic function reports 0 branches; should be 1 #864
A linear function, with no ifs etc., reports a branch count of zero. (Adding an if boosts it to 2.) This results in a much less useful "Branches" coverage number, because uninvoked linear functions don't count against coverage. Counting a linear function as one branch would make the number more useful for rigorous testing (more below), and I can't think of a way that it would be problematic for others. I would therefore like to suggest that linear functions change to count as one branch instead of none.
(The following wall of text is the captured result of a week of debate with a coworker. :) Please forgive the air of 'splainin' to the coverage experts!)
In structured testing (a rigorous, coverage-based approach to unit testing), branch coverage is the only metric that matters. It counts branches using cyclomatic complexity, which counts the number of paths through a function. Under that definition, "if the source code contained no control flow statements (conditionals or decision points), the complexity would be 1, since there would be only a single path through the code."
Cyclomatic complexity also counts "implied else" paths, which Istanbul does instrument, which is awesome, and which suggests that the Branches number is intended to be that rigorous!
(I've heard the argument that associates the word "branch" with "fork", where a linear function has no forks and therefore no branches, but on the other hand, if I break a single, unforking branch off a tree, it remains a branch. I think colloquialisms support either case.)
I would therefore like to request that linear functions give a coverage count of 1 instead of 0.
A linear function, with no
ifs etc., reports a branch count of zero. (Adding anifboosts it to 2.) This results in a much less useful "Branches" coverage number, because uninvoked linear functions don't count against coverage. Counting a linear function as one branch would make the number more useful for rigorous testing (more below), and I can't think of a way that it would be problematic for others. I would therefore like to suggest that linear functions change to count as one branch instead of none.(The following wall of text is the captured result of a week of debate with a coworker. :) Please forgive the air of 'splainin' to the coverage experts!)
In structured testing (a rigorous, coverage-based approach to unit testing), branch coverage is the only metric that matters. It counts branches using cyclomatic complexity, which counts the number of paths through a function. Under that definition, "if the source code contained no control flow statements (conditionals or decision points), the complexity would be 1, since there would be only a single path through the code."
Cyclomatic complexity also counts "implied else" paths, which Istanbul does instrument, which is awesome, and which suggests that the Branches number is intended to be that rigorous!
(I've heard the argument that associates the word "branch" with "fork", where a linear function has no forks and therefore no branches, but on the other hand, if I break a single, unforking branch off a tree, it remains a branch. I think colloquialisms support either case.)
I would therefore like to request that linear functions give a coverage count of 1 instead of 0.