Add actual but not expected items in the contains exactly matcher

[brunsa2]

Contain exactly would previously not show any diff if there were things in the actual list that weren't in the expected list, but this is still a failure case.

[mcmire]

I think this might be a solution for #96. So at a glance this looks good, but let me try this out in a test project to make sure.

[brunsa2]

I'm still going to try to figure out what's going on here (I haven't exactly figured out how match works yet), but it appears that through match it's not going to contains_exactly. @mcmire Do you know where the match pathway goes and what differ or whatnot is used here?

[mcmire]

Hey @brunsa2, sorry for the delay in responding. The tests you changed in match_matcher_spec look like they have to do with a_collection_including and not a_collection_containing_exactly. So I don't think you need to change those. However, you're in the right file, it just might be more beneficial to add to or change the tests for a_collection_containing_exactly. Does that make sense?

[brunsa2]

I'm not following. I'd expect contains_exactly and a_collection_containing_exactly to behave the same, but it appears that they are not following the same code path (or else the changes to collection_containing_exactly.rb should reflect in the match tests for a collection containing.

[brunsa2]

Thoughts: put the extra actual values in order rather than at the end.

• In favor: might be helpful if the diff matches the actual array order for debugging purposes
• In opposition: this matcher is meant to be order-independent and this would not reinforce that.

expect [a, b, c] to contain exactly [a, c]
  a
  c
+ b

vs.

expect [a, b, c] to contain exactly [a, c]
  a
+ b
  c

(I originally though the second was better but now like the first, as it currently stands, better again)

[brunsa2]

@mcmire CI is now failing before starting. I've tried twice.

[mcmire]

@brunsa2 Sorry about that. I just found out recently that a new release of RSpec broke the build. To add to this, Travis is switching over to a paid model, so CI builds take forever to run. I'm working on switching over to GitHub Actions and fixing the gem at the same time. Stay tuned!

[mcmire]

@brunsa2 Okay, the build is fixed and CI is now running against GitHub Actions instead of Travis. Try rebasing your branch against master!

[brunsa2]

Unless you're interested in changes from #106 (comment) I think this is ready, but there's a en extra "test" line waiting for status (not associated to a particular test config) that's holding off CI.

[brunsa2]

@mcmire if you missed it

[brunsa2]

@mcmire

[brunsa2]

@mcmire

[mcmire]

I apologize. I have been tending to other things. I will take a look at this tonight.

[mcmire]

I don't know why it's showing the build as not completed yet, because it is. Re: changing how the diff is presented, I don't know if I have an opinion on that right now. I can see both sides, but I feel like it's something that can be come back to. Anyway, I'll merge this. Sorry for the long wait and thank you!

[brunsa2]

Thanks :)