Open Bug 1740041 Opened 4 years ago Updated 3 years ago

Add a linter for conditionals in the first argument to `ok()` and `Assert.ok()`

Categories

(Developer Infrastructure :: Lint and Formatting, task)

Tracking

(Not tracked)

People

(Reporter: Gijs, Unassigned)

Details

I just reviewed a patch that did something like this:

ok(a == "5" && b == "6" && c == "7", "Some message")

This is bad because if the assertion fails it will say "TEST-UNEXPECTED-FAIL - got false, expected true - Some message", and that is pretty much useless for figuring out what went wrong, so when you get intermittent failures then (a) the messaging for the summary is rubbish and results in poor matching of failures to intermittents and (b) if it's high-frequency enough that engineering needs to investigate, step 0 will be figuring out what the failing thing even is, to be followed by figuring out why it's failing etc. All of that is annoying and could be improved by better use of the assertion APIs.

This should use 3 is statements that pass a/b/c and their expected counterparts. Or, in the case of my review where a/b/c were array elements, should use Assert.deepEqual to do the array comparisons.

I expect we'll have plenty of pre-existing uses of this, but I wonder if we could add a warning for this pattern to discourage future uses.

Product: Firefox Build System → Developer Infrastructure
You need to log in before you can comment on or make changes to this bug.