Matcher for part of object properties about earl HOT 11 CLOSED

@all-contributors please add @krzysztof-jelski for ideas

from earl.

We already have expect.containerWith for iterables and we still need arrayWith and objectWith.

This is tracked in: #48 so I'll close this as a duplicate.

It will be done during the weekend by me but you can contribute it if you want earlier :-> It's a simple matcher and we have already similar ones.

from earl.

Why close this? The issue is about a validator, not a matcher (even though the name matcher is used)

from earl.

Uhh, I thought it's about matchers. Linking to our docs for completeness: https://earljs.dev/docs/introduction/core-concepts

Still, my thinking is that we don't need validators duplicating what can be easily achieved with existing validators + matchers. For example:

expect({a: 1, b: 2, c: 3}).toContainSubset({a: 1, c: 3})

Is the same as:

expect({a: 1, b: 2, c: 3}).toEqual(expect.objectWith({a: 1, c: 3}))

Matchers are in principle more powerful than validators as they can be used in many different contexts (for example in given of mocks) and they compose well.

I don't have a very strong opinion on this as I already saw with toThrow that it's not always a good idea to embrace matchers 😆 But if we decide to introduce these validators, their naming should be inlined with matchers to make it clear that it's a shorthand.

I'll reopen to discuss.

from earl.

Personally i believe it is good to have duplication in this particular case. Possibly also with expect.a we could have expect(x).toBeA validator.

All in all it comes down to the fact that the code should be the most descriptive, since the tests serve as specification. So it is more descriptive to write expect([1, 2]).toContain(1) than expect([1, 2]).toEqual(expect.arrayWith(1)). The second, while more powerful introduces a lot of noise, potentially leading to people thinking functionality like this is missing.

from earl.

Okay I agree that these validators would be handy indeed. Lets start with:

• expect(x).toBeA(...) uses expect.a
• expect(x).toBeContainerWith uses expect.containerWith
• expect(x).toBeArrayWith uses expect.arrayWith
• expect(x).toBeObjectWith uses expect.objectWith

Note: I renamed toContainSubset proposed by @krzysztof-jelski to something that goes well with the names that we picked for matchers.

Let me know if you have any naming suggestions.

from earl.

Yes, the naming looks perfect 👌

from earl.

Hmm perhaps grammar-wise we should add an indefinite article in each one, as in:

expect(x).toBeAnObjectWith

from earl.

Yeah, I wondered about this too. I will check how other libs go about it, after all, we don't have expect.a.objectWith() 🤷

from earl.

@sz-piotr do you have any opinions on naming here?

from earl.

I'd prefer something grammatically correct. So definitely toBeAContainerWith and toBeAnArrayWith over toBeContainerWith and toBeArrayWith. I'd also propose renaming toBeAContainerWith to toContain

from earl.