Github Actions: Fix coverage task

[rwaldron]

No description provided.

[dtex]

There are a couple of things I'm noticing.

First, when running npm test locally, my machine reports a failure on the sip.js IMU -- BNO055 data test. By the time the setInterval callback has fired on my machine, the i2cReadOnce stub has been called two or three times. Note that before the setInterval call, the callCount is zero. This change gets past that, but then the callCount is off which causes the tests to fail. We need to find out why i2cReadOnce is firing multiple times in the 11-12 ms it takes for the callback to be triggered, decide if that is expected behavior, and then re-swizzle this test.

@scottgonzalez Do you recall why that change was made? I'm sure it was purposeful, but it seems to cause a problem.

Next, when running npm run coveralls locally, this same callCount never increments, the callback never fires, and the callback contains the test.done() call, so the tests never move on. This is probably a different problem.

[dtex]

Regarding the first issue, the first firing of i2cReadOnce comes from sip. The others are coming from the proximity.js SRF-10 read callback (line 100).

[scottgonzalez]

I made the change because the test was failing and the check for exactly 1 would mean that the failure of too many calls would keep the interval around. The change causes the test to properly fail on the call count assertion a few lines later rather than leaving the interval running forever.

[dtex]

That totally makes sense, and thanks for the quick reply. I'll see if I can figure out a good way to distinguish calls to i2cReadOnce between sip and proximity.