Remove CollectionContainsConstraint

[mikkelbu]

There is some code duplication between
DictionaryContainsKeyConstraint and
DictionaryContainsValueConstraint, but
I feel that not much will be saved by extracting
Matches and Using to a helper class.

Also I'm a bit unsure when to use Has.Some.EqualTo or
new SomeItemsConstraint(new EqualConstraint(expected)).

Fixes #1324

[rprouse]

Sorry we haven't looked at this yet, we've been busy working in other areas. I have self assigned myself as a reviewer so I won't forget. I am off on vacation this afternoon. Hopefully I will find time while I am away. Other @nunit/core-team or @nunit/framework-team team members, feel free to review. You don't have to wait for me.

[jnm2]

I'm all for cleaning things up, but what if end users have code that uses CollectionContainsConstraint? Shouldn't we at least obsolete it for a while first?

[mikkelbu]

No need to be sorry, the PR is not that old (and I've been waiting a lot longer than 1-2 weeks for a review in other repositories 😄 ).

Wrt. whether we should obsolete-mark {{CollectionContainsConstraint}} or not, I will let the teams decide. We can always keep the PR and apply it later.

[jnm2]

I missed this comment: #1324 (comment)

Looks like the decision is to remove. 👍

[ChrisMaddock]

Hey @mikkelbu. Sorry it took me a while to get round to looking at this one. Looks mostly good to me - just one point we need to address with CollectionContainsConstraint.Using, that I've commented on below.

I agree with your point about duplication between DictionaryKey/ValueContains - it's not worth worrying about.

Given there's no time urgency on this one at all, I'd personally prefer to see us [obsolete] the CollectionContainsConstraint constructor in v3.8, and then merge this into 3.9. I doubt this change will affect many people, but I given this isn't blocking anything, I think we can afford to go about it 'the nice way'. 😄

@nunit/framework-team - would also be good if someone would give this a second review before merging, there's a fair bit going on here, and I've never been that good at thinking through potential side effects! 🙂

[ChrisMaddock]

If we're going to do this as much as possible as a 'non-breaking change',wouldn't we need to add this Using signature to EqualConstraint? I'm not totally keen, as it would clutter up EqualConstraint, but think it's necessary to avoid breaking any existing tests.

i.e. Consider the below scenario, which would work with the CollectionContainsConstraint, but would no longer compile after these changes.

@nunit/framework-team - someone double check my logic, I'm not missing something here, am I?

@mikkelbu - if I'm right, then looks like we're missing a test for this case! Would you mind adding one when you come back to make the changes?

[jnm2]

@ChrisMaddock I think you are correct.

[rprouse]

@ChrisMaddock, I think you are correct. @mikkelbu, would you mind making an update to address this? Other than that, looks good.

[jnm2]

@ChrisMaddock You seem pretty darn good at thinking through potential side effects to me!

As far as I can see, that's the only breaking change besides removal of the class itself. All APIs on CollectionContainsConstraint must be moved to EqualConstraint.

[mikkelbu]

@nunit/framework-team I've reintroduced CollectionContainsConstraint (as it is on master) and I've added the Using overload to EqualConstraint (and a test thereof). Since there are Conflicting files I'm a bit unsure what to do (I'm primarily a mercurial user and need to look up most "advanced" git commands on stackoverflow 😄).

I guess that I can rebase my topic branch on top of master and then do a force push, but is that the normal approach in this project (and how do I do it).

[ChrisMaddock]

Changes look good!

[ChrisMaddock]

I guess that I can rebase my topic branch on top of master and then do a force push, but is that the normal approach in this project (and how do I do it).

Yes, force pushing is the normal approach.

I'm also a mercurial user. 😄 So don't take this as gospel - but I normally do something a bit like this. There's likely a better way!

git checkout master
git pull origin master
git checkout remove-CollectionContainsConstraint
git rebase master
///git will prompt you to resolve conflicts during this stage
git push origin remove-CollectionContainsConstraint -f

Edit: Actually, are you using a fork, rather than a branch in the main repository? In that case, it's more complicated - and I may defer to someone else to advise!

[mikkelbu]

Yes. I'm using a fork. I had no idea that it would make it more complicated. From what I can read in https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history the only difference is just that I need to rebase on top of upstream/master and not my own master.

[ChrisMaddock]

@mikkelbu - yep, that bottom list from your link looks sensible. 😄

# Point our `upstream` remote to the original fork
git remote add upstream https://github.com/thoughtbot/factory_girl.git

# Fetch latest commits from `upstream` (the original fork)
git fetch upstream

# Checkout our feature branch
git checkout feature

# Reapply it onto upstream's master
git rebase upstream/master

# Fix conflicts, then `git rebase --continue`, repeat until done
# Push to our fork
git push --force origin feature

[jnm2]

@mikkelbu Yeah, I don't even allow a master branch to exist in my forks because it serves no purpose and is always out of date. First thing I do after a fork is git checkout upstream/master -b feature_branch_name, git push -u origin feature_branch_name, and use GitHub to change the default branch to feature_branch_name and delete master and any other branches that were forked.

[CharliePoole]

I see the point on forks, but if you have master locally, it can be very convenient, especially if you are offline some of the time. Of course, you have to keep it up to date.

@mikkelbu You're a committer so you can make branches locally rather than in a fork, you know.

[jnm2]

@CharliePoole You always have upstream/master locally when you git fetch, so it's having master locally in addition to having upstream/master locally that I'm complaining about. You don't need both.

[CharliePoole]

If it's my own project, as opposed to somebody else's that I'm forking, I like to have a working directory for master because it's easier to scan through the code that way.

[jnm2]

That makes sense. I haven't had experience forking any of my own projects yet.

[CharliePoole]

I think you missed that I was making a distinction between forking and working on your own project directly.

[jnm2]

Oh, I did.

[rprouse]

@mikkelbu this looks good. I will resolve the conflicts and merge.

[mikkelbu]

Thanks @rprouse 👍