.not.have.keys incorrectly failing

[meeber]

Because of this line (I presume), the following tests both fail:

expect({a: 1, b: 2, c: 3}).to.have.keys('a', 'b');  // Correctly fails
expect({a: 1, b: 2, c: 3}).to.not.have.keys('a', 'b'); // Should pass but it fails too

The second test is incorrectly failing; it should pass right away on the basis that the target and given values don't have the same number of keys, which is a requirement when the contains flag isn't set.

[leggsimon]

Personally I would say that semantically both of those seem like they should fail. One of the best things about Chai is it's human readability. To which both of these seem wrong.

---

Given the examples above

expect({a: 1, b: 2, c: 3}).to.have.keys('a', 'b'); // I would've expected to pass

I would have expected to pass. To have the behaviour that I guess is the correct behaviour for that assertion (failing) I would expect something like

expect({a: 1, b: 2, c: 3}).to.have.exact.keys('a', 'b'); 
// or
expect({a: 1, b: 2, c: 3}).to.only.have.keys('a', 'b'); 

Semantically I would expect both of these to fail when reading them.

---

Likewise, the second one, semantically, I think should fail,
{a: 1, b: 2, c: 3} has got keys 'a' & 'b'.

[meeber]

@leggsimon Yeah, we have a bit of a problem right now with some of our list-like assertions. The default behavior is inconsistent among them, and there's also inconsistency in how they interact with the contains, any, and all flags. A detailed description of .keys current behavior is documented here, and #881 goes into more details about some of the inconsistencies among different assertions.

Right now, the problem described in this issue is considered a bug because it doesn't match the currently documented behavior of .keys. It needs to be fixed in the short term.

In the long term, a major change needs to be made to bring all of these related assertions into a state of consistency. I agree with you that given the two options below, the first seems more semantic:

1. Default behavior is that the target keys can be a superset of the given keys. Adding the .exact or .only flag makes it so that target keys and given keys must be identical sets.

2. Default behavior is that the target keys and given keys must be identical sets. Adding the .contains or .includes flag makes it so that the target keys can be a superset of the given keys.

Unfortunately, the second option was originally chosen, and to change it to the first option now at this point in the project will be an enormous breaking change. Given the current state of things, it'll be much smaller of a breaking change to bring all of the assertions in-line with the second option than the first option. Even though the first option is better, I don't know if it's better enough to justify the degree of breakage that it'll cause in a project of Chai's maturity. Never an easy decision.