1259617 - Most assertEq() calls in webRequest tests have wrong arguments order

Status: RESOLVED DUPLICATE of bug 1314492

(WebExtensions :: General, defect, P5)

Description

[Giorgio Maone [:ma1]]

While testing my additions and changes to the webRequest API I've been quite frustrated initially, before realizing that "got" and "expected" were often inverted in assertEq() tests. Gonna fix all them in this bug.

Comment 1

[Giorgio Maone [:ma1]]

Leaving it to some new developer who can use an easy way to familiarize with tests.

Comment 2

[Matthew Wein [:mattw]]

Maybe we could do something to naturally push for the correct order in the future?

One option, which I personally favor, would be to have `assertEq` take an object, like: 

assertEq({
 expected,
 actual,
 errorMessage, /* optional */
});

Comment 3

[Kris Maglione [:kmag]]

Giorgio, do you mind handling this? I agree this is easy, but I'm not sure it's a great first bug.

(In reply to Matthew Wein [:mattw] from comment #2)
> Maybe we could do something to naturally push for the correct order in the
> future?
> 
> One option, which I personally favor, would be to have `assertEq` take an
> object, like: 
> 
> assertEq({
>  expected,
>  actual,
>  errorMessage, /* optional */
> });

I think that gets a bit verbose when you have to look at it dozens of times in the same function.

In any case, this API is derived from a Chromium API, so there are drawbacks to changing the call contract.

Comment 4

[Shane Caraveo (:mixedpuppy)]

I fixed this in the refactoring in bug 1314492