You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The result is a very hard to track down branch coverage shortcoming with no visual indication in the reports. Once stepping through the coverage report JSON, you find a line 0/column 0 branch.
Test Case
Code
window.foo= (arr) ->for val in arr when val?window.handleExisting val
returnwindow.handleExisting= (i) ->return i +1
The coverage reports incomplete branch coverage. In this simple code, it is obvious why: when val? never gets hit with an undefined value. However, this does not get indicated in the coverage report.
Further investigation shows the following JSON (relevant parts only):
Obviously, this branching is not occurring on the non-existent line 0.
To other people finding this issue and need a quick way to track down the uncovered branch:
Go into debug mode of your test runner (I use Karma), or somehow otherwise get ahold of the coverage JSON object
On the coverage object, look through the b key. This key contains branch coverage totals. The b key holds an object of key/value pairs where the key is the branch ID internal to the coverage reporter, and the value is an array of coverage hits. Find the value in b where there is at least one coverage hit of 0 (meaning the branch was never reached). Then take the corresponding ID (in the case above, "1") and access the corresponding branchMap (eg, as above, branchMap["1"]). This branch map metadata will be unhelpful on it's own, as it misreports the line and column, but the branchMap numbering is in order of top of file to bottom of file so if you look at the branches immediately before and after, you will find correct branch coverage data including real line numbers, and your missing branch should lie between these two line numbers. For example, if you are looking at branchMap["32"] because the b["32"] contains a value like [4, 0] (meaning the secondary part of the branch was hit 0 times and thus is the culprit), you should also look at branchMap["31"] and branchMap["33"]. If branchMap["31"] is on line number 180 and branchMap["33"] is on line number 210, then you know branchMap["32"] lies somewhere between 180 and 210, even though it has the erroneous line number of 0.
The text was updated successfully, but these errors were encountered:
The result is a very hard to track down branch coverage shortcoming with no visual indication in the reports. Once stepping through the coverage report JSON, you find a line 0/column 0 branch.
Test Case
Code
Test
The coverage reports incomplete branch coverage. In this simple code, it is obvious why:
when val?
never gets hit with anundefined
value. However, this does not get indicated in the coverage report.Further investigation shows the following JSON (relevant parts only):
Obviously, this branching is not occurring on the non-existent line 0.
To other people finding this issue and need a quick way to track down the uncovered branch:
b
key. This key contains branch coverage totals. Theb
key holds an object of key/value pairs where the key is the branch ID internal to the coverage reporter, and the value is an array of coverage hits. Find the value inb
where there is at least one coverage hit of 0 (meaning the branch was never reached). Then take the corresponding ID (in the case above,"1"
) and access the correspondingbranchMap
(eg, as above,branchMap["1"]
). This branch map metadata will be unhelpful on it's own, as it misreports the line and column, but the branchMap numbering is in order of top of file to bottom of file so if you look at the branches immediately before and after, you will find correct branch coverage data including real line numbers, and your missing branch should lie between these two line numbers. For example, if you are looking atbranchMap["32"]
because theb["32"]
contains a value like[4, 0]
(meaning the secondary part of the branch was hit0
times and thus is the culprit), you should also look atbranchMap["31"]
andbranchMap["33"]
. IfbranchMap["31"]
is on line number 180 andbranchMap["33"]
is on line number 210, then you knowbranchMap["32"]
lies somewhere between 180 and 210, even though it has the erroneous line number of 0.The text was updated successfully, but these errors were encountered: