to satisfy: compare functions by value

[papandreou]

This PR changes to satisfy to stop calling functions on the RHS with the value on the LHS, this behavior was too surprising. To replicate the old behavior you would have to use expect.it(v => ...) instead.

Before:
(It is only in rare circumstances you need this functionality as you can usually just use a normal expect.it expression.

expect({
  value: 42
}, 'to satisfy', {
  value: v => {
    expect(v, 'to be a number')
  }
})

After:

expect({
  value: 42
}, 'to satisfy', {
  value: expect.it(v => {
    expect(v, 'to be a number')
  })
})

We still support using a function in places where it is not confusing:

expect(
  [0, 1, 2, 3, 4, 5],
  'to have values satisfying', (v) => {
    expect(v, 'to be a number')
  }
)

(This is also a rare case as you can write the same like this:

expect(
  [0, 1, 2, 3, 4, 5],
  'to have values satisfying', 
  'to be a number'
)

[papandreou]

@sunesimonsen, mind if I land ed4873e on its own? It seems pretty uncontroversial and provides that "escape" in a forwards compatible way, should we end up landing the rest of this (in a fixed up version :).

[papandreou]

Got bitten by this yesterday where I did something like this:

expect(myFunction, 'to call the callback with error', httpErrors.BadRequest);

The mistake is that httpErrors.BadRequest is a function, not an error instance. I should have written new httpErrors.BadRequest(). That lead to a silent error because the assertion boiled down to expect(new httpErrors.Conflict(), 'to satisfy', httpErrors.BadRequest), and that passes because httpErrors.BadRequest doesn't throw when passed an existing error instance.

To me that serves as a good example of why special casing functions in to satisfy RHS is a bad idea and we should fix it.

[sunesimonsen]

I agree, that is too surprising. Let's do it.

[papandreou]

@sunesimonsen Cool! Then we just need to figure out how to fix those failing tests. I remember I felt pretty stuck.

[sunesimonsen]

I can try to take a look at it. But this weekend is occupied.

[papandreou]

Appreciated :)

[sunesimonsen]

We should get this rebased and pick it up again. Sorry for never returning to the issue.

[papandreou]

Rebased.

[papandreou]

... And no worries, this isn't exactly a high priority thing, since it requires a major version bump.

[alexjeffburke]

@papandreou the more I think about it the more I think this is a good idea. Question - I believe it should be possible to identify the cases that this change will no longer allow, for the sake of any large user of Unexpected I wonder if we might want to consider a release of v10 that actually warned this will be deprecated in v11? It could be seriously helpful for any large Unexpected user (ourselves at $work included) to check we don't rely on this. And for the record, I guess this is me sort of volunteering.. 🧐

[sunesimonsen]

I guess this is me sort of volunteering..

❤️

[sunesimonsen]

I don't think the deprecation is a good idea now that we have a way forward and then we can remove the functionality in v11.

[sunesimonsen]

@papandreou I'm pretty sure that we need to be able to detect when an expect.it(v => ...) function wrappers is used and handle it in the to satisfy object diff like we did with the functions before. I'll do fix this, but it wont happen tonight :-)

[papandreou]

@sunesimonsen, thanks, looking forward to it! (Kinda relieved that it wasn't easy :)

[sunesimonsen]

Mhh this is more complicated than I though, you can in principal do this:

expect({ foo: 'text' }, 'to satisfy', {
  foo: expect.it('to be a string').and(v => expect(v, 'to match', /ext$/))
})

[papandreou]

Hmm, yeah, you're right. We've supported that since 10.28.0 due to b562c46

It's probably a well kept secret, so I think we can consider unsupporting it if it makes this really hard.

[sunesimonsen]

@papandreou what I'm trying to get at, is that you can basically do anything, so it is kind of hard to inline the diff - and know when that is the right thing to do. I'm actually a little puzzled about the old behavior.

[sunesimonsen]

I think we need to write some more tests for the expect.it(subject => ...) handling. But other than that, this PR now looks like it is working.

[papandreou]

😌

[papandreou]

Should be fine to use arrow functions here, as long as they're not part of the expected error message.

[papandreou]

Looks great, thanks so much for fixing it up! I can't approve because I originally opened the PR, but !

[alexjeffburke]

I really like this. It is my firm belief that it cleans up a potentially confusing inconsistency and provides a very uniform story around how to go about comparing values.

With the understanding that the expect.it(value => is a bit of a special case, I think it's very
powerful tool and expect.it is the right place for it. Ultimately users always have the power of the language available to them and making it regular is a huge plus.

[alexjeffburke]

I think it's a nice outcome that type check ends up being for expect.it specifically while shifted values gets dispatched the same way. Nice.

[alexjeffburke]

A final thought while looking at this - there may be other implementations of "to satisfy" that need to catch up with this. I think at least U-map (since it sadly had to duplicate quite a bit). I'd love to catch that in an automated way but it might be that test cases need to be added. What do you both think?

[papandreou]

@alexjeffburke, could be! Let's hope we have good test coverage in those plugins 👿