Closed Bug 1633883 Opened 4 years ago Closed 3 years ago

`TelemetryTestUtils.assertScalar` will probably do the wrong thing if `value` is `0`

Categories

(Toolkit :: Telemetry, defect, P3)

defect

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox78 --- wontfix
firefox91 --- fixed

People

(Reporter: chutten, Assigned: Mardak)

References

Details

Attachments

(1 file)

TelemetryTestUtils.assertScalar checks if the value passed in is > 0 before asserting that the value is equal. This will not ensure that, e.g., a bool scalar is false.

Maybe we should fix that.

assertKeyedScalar doesn't do it this way.

Severity: -- → S4

This almost caused me trouble. I was planning to encode errors as the value 0, and I was writing a test to verify this functionality. Because of this unusual behavior, I will probably use a different value to convey errors.

To instead work around the error, please feel free to use the following workaround:

Assert.ok(scalarName in scalars && scalars[scalarName] === value, msg)

Huh, and the docstring suggests that the function only works for uint scalars:

@param {Number} value The expected value for the provided scalar.

Curious.

Allow both 0 and undefined to have TelemetryTestUtils.assertScalar check for not reported scalar.

Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #9226411 - Attachment description: Bug 1633883 - TelemetryTestUtils.assertScalar assumes Number (so behaves odd for boolean, strings) r?Standard8 → Bug 1633883 - TelemetryTestUtils.assertScalar assumes Number (so behaves odd for boolean, strings) r=chutten!
Pushed by elee@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1fc9f15ae2af
TelemetryTestUtils.assertScalar assumes Number (so behaves odd for boolean, strings) r=chutten
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: