How can I test for an ordered subset with gaps between the elements?

[shepmaster]

I have an array of Redux actions, some of which I care about and some which I don't. I do care about the order (an async request had better come before a response! 😇 ).

I tried code like this with Chai 4.1.2:

chai.expect([1,2,3,4,5]).to.include.ordered.members([1,3,5]);
chai.expect([1,2,3,4,5]).to.deep.include.ordered.members([1,3,5]); // also

Which yields the error:

expected [ 1, 2, 3, 4, 5 ] to be an ordered superset of [ 1, 3, 5 ]

Reading through #717, it appears that this was deliberate:

expect([1, 2, 3]).to.include.ordered.members([1, 2]);
expect([1, 2, 3]).to.include.ordered.members([2, 3]);

I'm leaning toward only the first passing, as I suspect it's a more common use case to test that an array begins with an ordered subset.

What is the correct syntax to say "element A must come before B, which must come before C, which ..."?

Thanks for the great library!

[meeber]

@shepmaster I don't think there's a simple way to do that currently. It's very possible that we used the wrong algorithm for .include.ordered, and that it should instead behave as you've described, matching members as long as they appear in the same order, even if there are elements in between the matches in one or both arrays. Interested to hear other thoughts @keithamus @lucasfcosta @vieiralucas @shvaikalesh.

In the meantime, your best bet may be to either include the actions you don't care about in the assertion, or filter the array prior to the assertion to only include the ones you care about.

[shepmaster]

Thanks!

possible that we used the wrong algorithm

Without thinking too deeply on it, it seems changing it now would not be a backwards-compatible change; do you agree? We might need to come up with a new name if the new algorithm seems useful...

include the actions you don't care about in the assertion

In this case, I can't easily do that because the actions I'd like to ignore actually have unique IDs in them, which makes it pretty hard to control :-)

filter the array prior to the assertion

That was my second thought as well, but it's a little ugly as I have to dig into the internals of each element to figure out which ones to keep and which to discard. I can certainly do this if there is no better solution we can come up with.

[meeber]

When .ordered was added, it was mostly for the .have.ordered functionality. The .include.ordered was a last-minute "oh wait how is this supposed to work?" It'd be a breaking change, but I'm not opposed to pursuing it if there's consensus.

Regarding filtering: Don't you just need to know the ones you're keeping, which are the same ones you're testing for?

[Izhaki]

Same issue here, albeit not redux.

Actual:

      [ { message: 'fillStyle', args: [ 'transparent' ] },
        { message: 'strokeStyle', args: [ 'black' ] },
        { message: 'strokeStyle', args: [ 'purple' ] },
        { message: 'beginPath', args: [] },
        { message: 'arc', args: [ 140, 100, 50, 0, 6.283185307179586 ] },
        { message: 'stroke', args: [] } ]

And we test it like this:

    expect(ctx.calls).to.deep.include.members([
      { message: 'strokeStyle', args: ['purple'] },
      { message: 'beginPath', args: [] },
      { message: 'arc', args: [140, 100, 50, 0, 6.283185307179586] },
      { message: 'stroke', args: [] },
    ]);

But that doesn't assert on the order.

[keithamus]

I'd be happy if the semantics matched those described in the original comment. It seems to make sense to me 👍

[keithamus]

Hey @shepmaster thanks for the issue.

We've added this to our Roadmap https://github.com/chaijs/chai/projects/2! We'll be releasing chai 5 soon, but for now I'll close this issue because it is tracked on our roadmap.