-
-
Notifications
You must be signed in to change notification settings - Fork 398
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
Incorrect output with a reused argument matcher #1287
Comments
pirj
added a commit
to rubocop/rspec-style-guide
that referenced
this issue
Feb 3, 2021
Reusage may have undesired side effects. See rspec/rspec-expectations#1287 https://github.com/rspec/rspec-expectations/blob/bd10f0cf3970932781efcd09b5e427877d16a6c2/lib/rspec/matchers/composable.rb#L113 # Historically, a single matcher instance was only checked # against a single value. Given that the matcher was only # used once, it's been common to memoize some intermediate # calculation that is derived from the `actual` value in # order to reuse that intermediate result in the failure # message. # # This can cause a problem when using such a matcher as an # argument to another matcher in a composed matcher expression, # since the matcher instance may be checked against multiple # values and produce invalid results due to the memoization. # # To deal with this, we clone any matchers in `expected` via # this method when using `values_match?`, so that any memoization # does not "leak" between checks. rspec/rspec-expectations#518
Some output must be cached between runs, we are supposed to be allowing this use case. |
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 12, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 12, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 12, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 12, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 12, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 13, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Oct 15, 2021
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by reinitializing the matcher's state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Apr 25, 2022
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by overriding ContainExactly#matches?, reinitializing its internal state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
bclayman-sq
added a commit
to bclayman-sq/rspec-expectations
that referenced
this issue
Apr 26, 2022
This addresses issue rspec#1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by overriding ContainExactly#matches?, reinitializing its internal state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
Fixed in #1326 |
pirj
pushed a commit
that referenced
this issue
Nov 1, 2022
This addresses issue #1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by overriding ContainExactly#matches?, reinitializing its internal state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
pirj
pushed a commit
that referenced
this issue
Nov 1, 2022
This addresses issue #1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by overriding ContainExactly#matches?, reinitializing its internal state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
JonRowe
pushed a commit
that referenced
this issue
Nov 10, 2022
This addresses issue #1287. Previously, matchers retained state after being used as an argument to RSpec::Expectations::ExpectationTarget#to. This caused incorrect results when reusing a matcher in subsequent expectations. This PR addresses the issue by overriding ContainExactly#matches?, reinitializing its internal state when the matcher is reused. Co-authored by: Rai Feren <rferen@squareup.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Subject of the issue
The second failure message seems to have traces from the first evaluation:
It appears that
with_matchers_cloned
(lib/rspec/matchers/composable.rb
) doesn't cover this case.Adding
.clone
or.dup
to.to matcher
solves the issue.Your environment
Expected behavior
Actual behavior
The text was updated successfully, but these errors were encountered: