Andri Möll

Hey! Thanks for taking the time to think along! Definitely, something akin to that would be useful. Going further, I think there are a few related possible matchers: 1. Matching...

Morning! Actually I think you could use the former with promises. ``` js // When using Mocha to return a promise: return Promise.all([ obj.must.then.have.property("foo", 1), obj.must.then.have.property("bar", 2), ]) // When...

Hey again! I added `Must.prototype.properties` and `Must.prototype.ownProperties` (https://github.com/moll/js-must/blob/master/CHANGELOG.md). While they don't yet cover the nested object assertion example you have above (`{body: {some: data}}`), they should be a start. :)...

Absolutely, a "nesting" matcher will be useful, too. While I don't find the short-is-more-lax pattern (inspired by `==` vs `===`) particularly intuitive, I'm thinking of naming the `eql`-based matcher `props`...

Hey, First off, sorry that this caused confusion! The reasoning behind it was to be as strict as possible by default on all matchers. False negatives in testing are less...

Thanks for your thoughts! I'll sleep on this a little and get back to you. The `atLeast.keys` or `have.keys` syntax (like Chai does it) though would be something I'd steer...

Aah, my bad for not elaborating what I meant. So, _less surprises_ when migrating is something I value, but that goes for things that are good design choices. Making _better_...

Definitely plan to add others. :) Just to double check, do I understand correctly that the decision you consider a bad one is that the `keys` matcher checks for every...

A few days ago I also realized that using the negative form of `keys` right now is either useless or confusing: ``` javascript obj.must.not.have.keys(["name", "age"]) ``` That would _pass_ if...

@koresar: > This is really a confusing syntax: object.must.include(someValueHere). Why value? To be honest, that was fairly arbitrary. I didn't have a good argument for either checking inclusion of keys...