(Possible) Bug in Lab Coverage Checker ?

[Nelson]

Hi @geek
Hope your day is going well.
I'm in the process of writing a (Fully Tested) Hapi.js + Socket.io + Redis Pub/Sub Example/Tutorial app... see: https://github.com/dwyl/hapi-socketio-redis-chat-example/

But, sadly I'm unable to get Lab code coverage checker to cooperate...

Lab coverage is convinced that a few lines of my code are not being covered by my tests, when they clearly are being executed!!

I don't understand ... 😢
If you (or anyone else in the illustrious list of contributors) can give me some insight I'd be super grateful!

Git Commit: dwyl/hapi-socketio-redis-chat-example@a8722bb

[David Bashford]

Having a similar issue. I switched from supertest/mocha+chai/istanbul and 100% coverage to server.inject/lab/lab and 99% without changing any code other than moving some tests around. Thinking the coverage is having issues with complex booleans?

https://coveralls.io/builds/3021647/source?filename=src%2Froute_builder.js

So getting knocked on the ifs, for instance, but not the content of the block?

[Nelson]

@dbashford thanks for your quick reply and for confirming I'm not going insane!
I too had 100% test coverage when using Istanbul, but switched to Lab because its the preferred testing framework for Hapi.js apps (which is what demo app I'm writing uses...)

The if(value_is_set) statement in the screenshot above is clearly being executed and both branches are being followed (hence the console.log is being printed - during the test!) I don't understand why Lab thinks the lines don't have coverage ... I don't consider if(value_is_set) to be "complex" code blocks ... 😿

What did you end up doing to re-gain your 100% test coverage?
I've tried adding more tests, but alas nothing seems to work.

Is this a "Bug" or a "Feature"...?

[Adri Van Houdt]

@nelsonic is there a test where the if block is not executed?

[Eran Hammer]

Is it possible the file is loaded and executed before lab does its thing?

[Wyatt Preul]

@nelsonic does the html report provide any additional clues, perhaps the conditional isn't needed?

[Nelson]

The lines in question are: https://github.com/dwyl/hapi-socketio-redis-chat-example/blob/a8722bbe4b641a187e2c0013312e6fbffd8c4496/lib/redis_config.js#L4-L12

And the test which executes them:
https://github.com/dwyl/hapi-socketio-redis-chat-example/blob/a8722bbe4b641a187e2c0013312e6fbffd8c4496/test/_redis_cloud.js#L14-L16

The test is simply loading a configuration file redis_config.js which will follow the first branch of the if because the process.env.REDISCLOUD_URL is indeed set.

We make sure to uncache the file on line 13 https://github.com/dwyl/hapi-socketio-redis-chat-example/blob/a8722bbe4b641a187e2c0013312e6fbffd8c4496/test/_redis_cloud.js#L13 so we are sure that the correct branch will be executed.

We explicitly console.log on line 5
https://github.com/dwyl/hapi-socketio-redis-chat-example/blob/a8722bbe4b641a187e2c0013312e6fbffd8c4496/lib/redis_config.js#L4-L5
inside the branch of the if which is shown in my original screenshot for this issue.

(thanks for helping investigate this...!)

[Maxime Bargiel]

I ran into an issue similar to this, perhaps this exact issue. It happens to me with lab 10.3.0 (no other dependencies needed).

The problem, I believe, is when an if conditional is checked for only true or false, when there is no else. In that case, we don't expect to have to also test the false condition, because there is no false path.

So assuming the following code:

// some stuff
if (myCondition) {
    // conditional stuff
}
// more stuff

Then assuming this code is tested with either myCondition or !myCondition, but not both, lab will report that the myCondition is not covered. I find this to be confusing, especially considering myCondition has been evaluated.

See the attached files for a very simple repro case.
if_condition_coverage_issue.zip

To run the test cases:
Full coverage: npm run test100
Missing coverage: npm run test50a (if only checked in true branch) and npm run test50b (if only checked in false branch).
For convenience, on windows: npm run test50a_win and npm run test50b_win.

[Nicolas Morel]

@mbargiel That's the expected behavior, the line is covered but if it's always true or always false what's the point of having it at all ?

[Maxime Bargiel]

While writing this feedback, I figured as much. Maybe the problem is how this information is reported, but I have no solution to offer, since the only output is basically a list of line numbers. I guess lab users "just have to know".

In my case, I may have to disable coverage for that if (because the if is always true in tests, and sometimes false outside of tests).

[Wyatt Preul]

@mbargiel this is now fixed in the html reporter, which shows parts of a line that can be removed

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.