Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add to_include matcher for collections and cursors #79

Closed
jgebal opened this Issue Oct 17, 2016 · 3 comments

Comments

2 participants
@jgebal
Copy link
Member

jgebal commented Oct 17, 2016

The inclusion matcher should allow us to tell that actual collection / cursor is a superset of the expected (includes expected)

@jgebal jgebal added this to the version3 milestone Oct 17, 2016

@jgebal jgebal modified the milestones: version3.1, version3 Dec 18, 2016

@jgebal jgebal added this to To Do in expectations Oct 25, 2017

@jgebal jgebal removed this from the v3.1.0 milestone Apr 23, 2018

@jgebal jgebal added idea and removed task labels Jun 19, 2018

@jgebal jgebal added the low_priority label Jul 9, 2018

@jgebal

This comment has been minimized.

Copy link
Member Author

jgebal commented Aug 9, 2018

A test should fail if expected set contains elements that are not part of actual set.
The exclude/include/join_by should still be respected.
The order should not be relevant, so the behavior should be unordered by default.
The unordered should not be supported

The simplified SQL representation of that comparison would be something like:

--ut.expect(actual).to_include(expected).join_by(pk) 
--ut.expect(actual).to_contain(expected).join_by(pk) 
select *
  from expected
    left join actual 
   on expected.pk = actual.pk
 where actual.row is null;

--ut.expect(actual).to_include(expected)
--ut.expect(actual).to_contain(expected)
select *
  from expected
    left join actual 
   on expected.row_hash = actual.row_hash
 where actual.row_hash is null;

The not_to_inculde should behave differently. As it should fail if any of rows that are expected is included.

--ut.expect(actual).to_include(expected).join_by(pk) 
--ut.expect(actual).to_contain(expected).join_by(pk) 
select *
  from expected
    left join actual 
   on expected.pk = actual.pk
 where actual.pk is not null;

--ut.expect(actual).to_include(expected)
--ut.expect(actual).to_contain(expected)
select *
  from expected
    left join actual 
   on expected.row_hash = actual.row_hash
 where actual.row_hash is not null;

Do you think it's worth implementing?
@lwasylow - do you think it would it be difficult to add?

@lwasylow

This comment has been minimized.

Copy link
Member

lwasylow commented Aug 10, 2018

No I don't think it will be hard to implement.
However join_by in such scenarios I think will not give benefit at all as we still want to match a content of the full row so regardless of match on key.

Example:

  1. Included fully ( no feedback to user needed possibly)
    2.Not included fully (present result as Expected and Missing )
  2. Partially included ( pk key exists however data content is different, but from logic point of view answer should be still Not Included )

Overall we looking on left outer join instead of full join on existing queries so yeah we should be able to do that fairly easy.

@lwasylow lwasylow self-assigned this Oct 4, 2018

@lwasylow

This comment has been minimized.

Copy link
Member

lwasylow commented Oct 6, 2018

Do we want to actually highlight differences as well ?
E.g. PK match but value in column is different ?
Or we want to treat that as missing ?

@lwasylow lwasylow added this to the v3.1.3 milestone Nov 2, 2018

@jgebal jgebal modified the milestones: v3.1.3, v3.1.4 Nov 20, 2018

@lwasylow lwasylow removed this from To Do in expectations Nov 27, 2018

@jgebal jgebal closed this in #801 Mar 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.