Breaking: Fix .include to always use strict equality
#760
Conversation
|
Yup, LGTM. @lucasfcosta? |
| @@ -221,6 +222,17 @@ module.exports = function (chai, _) { | |||
| * expect([1,2,3]).to.include(2); | |||
| * expect('foobar').to.contain('foo'); | |||
| * expect({ foo: 'bar', hello: 'universe' }).to.include({ foo: 'bar' }); | |||
| * | |||
| * By default, strict equality (===) is used. | |||
There was a problem hiding this comment.
Maybe this line isn't totally clear for anyone using the library.
When saying that this uses strict equality this may not be exactly clear for everyone. This is because when saying that this assertion uses this kind of comparison I would expect (if I just read the docs) the following assertion to throw an error:
expect({foo: obj1, bar: obj2}).to.include({foo: obj1});Because I would expect it to compare the object I passed as a parameter to the include method to the one I passed to expect, and, since they would not be the same instance, strict equality would be false and therefore I would expect an Error to be raised.
Maybe we could explain this a little better, just to make things as clear as possible, I'm not sure everyone will get it right this way.
What do you guys think?
There was a problem hiding this comment.
@lucasfcosta Agreed. Updated with an explanation.
- Previously, `.include` was using strict equality for non-negated property inclusion, but deep equality for negated property inclusion and array inclusion. This fix causes `.include` to always use strict equality.
|
@lucasfcosta @keithamus New version pushed! |
|
Excelent explanation. The inner working of this assertion is now very clear. |
.includewas using strict equality for non-negated propertyinclusion, but deep equality for negated property inclusion and array
inclusion. This fix causes
.includeto always use strict equality.Note:
.not.property(name, val)behavior #744, Breaking: Rename.deep.propertyto.nested.property#757, and Add.deep.propertyfor deep equality comparisons #758 are prerequisites for this PR. I recommend reviewing them first, and then only reviewing the newest commit in this PR.