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

Using fluent syntax unintentionally removed in 3.8 #2412

Closed
ChrisMaddock opened this issue Sep 4, 2017 · 8 comments · Fixed by #2447
Closed

Using fluent syntax unintentionally removed in 3.8 #2412

ChrisMaddock opened this issue Sep 4, 2017 · 8 comments · Fixed by #2447
Assignees
Labels
Milestone

Comments

@ChrisMaddock
Copy link
Member

From @BlythMeister on #2410
with regard to the example code, we had
Assert.That(myCollection, Contains.Item(expectedItem).Using(new MyCustomComparer()));
The .Using fluent method existed in 3.7, but was removed in 3.8.
I was unable to find an equivalent, so changed to
Assert.That(myCollection.Contains(expectedItem, new MyCustomComparer()));
Which was a simple enough change as a 1 off, but we had around 100 usages of that old syntax with different collection names, expected names as comparers (across different projects)

This change was unintentional - the removal of CollectionContainsConstraint wasn't intended to cause any breaking changes.

@mikkelbu did the below analysis of what happened:

@BlythMeister This is very unfortunate. Actually, @ChrisMaddock spotted the missing Using in aa19bd1 (see #2239 (comment)), so we added Using to the EqualConstraint in bd2091b. However, the entire PR did contain an error, so Contains.Item was again changed in 15c27e5 to return a ContainsConstraint instead of a EqualConstraint. And currently ContainsConstraint does not have a Using method.

@rprouse - will leave you to decide if this should be critical or not, possibly along with #2411 - I haven't looked into that one.

@mikkelbu
Copy link
Member

mikkelbu commented Sep 5, 2017

Before implementing a solution to this I think we should have tests that cover all the functionality of CollectionContainsConstraint - as it were in version 3.7 - and then use these tests to ensure that we have kept all the behaviour. I'll try to look into writing these tests tonight (if I have time). The tests should also cover #2411.

@rprouse rprouse changed the title Unintended breaking change Using fluent syntax unintentionally removed in 3.8 Sep 5, 2017
@rprouse
Copy link
Member

rprouse commented Sep 5, 2017

I updated the title of this issue to better reflect what it is. Feel free to reword if needed.

I think this could warrant another hotfix since I don't think there is a workaround. There is a hotfix for #2411, but we could include it if this one is going out.

As for unit tests, we have tons of syntax tests and constraints tests, but we lack many tests that purposefully chain constraints together. I was thinking we should add a series of fluent syntax tests that do just that. They could be simplistic tests that just set up what we know is passing data and exercise various combinations of constraints.

@CharliePoole
Copy link
Contributor

@rprouse I think we once had a test that covered almost all the syntax, including chaining things together. We may have eliminated it at some point in favor of more targeted tests. If so, it seems like that wasn't such a good idea. 😞 I'll take a look.

@mikkelbu
Copy link
Member

mikkelbu commented Sep 5, 2017

I've tried to go through all the changes done in #2239 and write tests for each change. All the tests pass in version 3.7.1, but in 3.8.1:

  • 5 does not compile (due to 'SomeItemsConstraint' does not contain a definition for 'Using'), and
  • 3 fails with System.ArgumentException : The actual value must be an IEnumerable

https://gist.github.com/mikkelbu/370fe6a735c41906dca1fad28282f19e

@ChrisMaddock
Copy link
Member Author

That test file looks great Mikkel. 👍 I'm surprised there was so much missing from our test suite. 😞

@mikkelbu mikkelbu self-assigned this Sep 9, 2017
@mikkelbu
Copy link
Member

mikkelbu commented Sep 9, 2017

@nunit/framework-and-engine-team I've assigned this issue and #2411 to myself, and I have a technical question (or two).

  • If these issues should be part of a hotfix should I then base my topicbranch on the release branch?
  • Is it okay if I solve both issues using one topicbranch or should I rather use two separate topic branches?
  • Should I also update CHANGES.md and increment the version number, or is this a job for the person responsible for creating the hotfix?

@rprouse
Copy link
Member

rprouse commented Sep 11, 2017

@mikkelbu you can base your changes on the master branch. I can cherry-pick the changes for the release. It would be easier to fix both issues in one PR since they are related. It will also make cherry picking the changes easier. Don't worry about updating CHANGES.md or the version number, I do that as part of the hotfix.

mikkelbu added a commit that referenced this issue Sep 17, 2017
Unfortunately need to implement a lot of Using
overloads in SomeItemsConstraint and a dynamic check.

Fixes #2411 and fixes #2412
@mikkelbu mikkelbu added this to the 3.8.2 milestone Sep 19, 2017
@mikkelbu
Copy link
Member

@rprouse I've added this issue to the 3.8.2 milestone.

@rprouse rprouse modified the milestones: 3.8.2, 3.9 Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants