Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent data type behavior of expect(object) #486

Closed
awvalenti opened this issue Jun 11, 2018 · 1 comment
Closed

Inconsistent data type behavior of expect(object) #486

awvalenti opened this issue Jun 11, 2018 · 1 comment
Assignees
Labels
Milestone

Comments

@awvalenti
Copy link

Consider this test:

request(url).get('/url').expect({ a: 1, b: 2});

This production code (both properties incorrect: a is string instead of number and b is 3 instead of 2)

res.status(201).json({a: '1', b: 3});

produces the following (correct) test result:

Error: expected { a: 1, b: 2 } response body, got { a: '1', b: 3 }
      + expected - actual

       {
      -  "a": "1"
      -  "b": 3
      +  "a": 1
      +  "b": 2
       }

However, this production code (a is still a string instead of number and b is correct)

res.status(201).json({ a: '1', b: 2 });

produces

1 passing (5ms)

In other words, current (incosistent) behavior is:

  • If all properties are ==, ok!
  • If they are not ==, compare them using === to show the result

The behavior should be the same in all cases. Presumably, only === should be used for comparison, producing the same result as deepEqual method from should library.

Temporary solution is to do:

.expect(res => res.body.should.deepEqual({ a: 1, b: 2 }));
@mikelax
Copy link
Contributor

mikelax commented Sep 5, 2018

@awvalenti yes that is currently a known limitation. The expect function is checking the response body using assert.deepEqual, which for primitives (of the object) does use ==.

I think the correct answer is to change this line to use .deepStrictEqual instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants