-
-
Notifications
You must be signed in to change notification settings - Fork 395
Allow satisfy
to match the block expectation return value
#1477
Conversation
8560395
to
690f7cd
Compare
satisfy
to match on the block expectation return valuesatisfy
to match the block expectation return value
778e977
to
bd5017c
Compare
cc @zverok WDYT? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay reviewing this @pirj definietly a good idea and good work but needs some tweaks
@@ -39,3 +53,20 @@ Feature: `satisfy` matcher | |||
| expected 10 to satisfy expression `v > 15` | | |||
| expected 10 not to be greater than 5 | | |||
| expected 10 to be greater than 15 | | |||
|
|||
@skip-when-ripper-unsupported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you just copy this tag or check to see if it works without it? I'd expect it to work without it as its not matching source.
# Passes if the submitted block returns true. | ||
# For value expectations, yields target to the block. | ||
# For block expectations, yields the expectation's returned value to the block. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Passes if the submitted block returns true. | |
# For value expectations, yields target to the block. | |
# For block expectations, yields the expectation's returned value to the block. | |
# Passes if the submitted block returns true. Yields targer to the | |
# block. This is either the direct value or the result of an `expect` block. |
@@ -11,6 +11,7 @@ Enhancements: | |||
|
|||
* Improve the IO emulation in the output capture matchers (`output(...).to_stdout` et al) | |||
by adding `as_tty` and `as_not_tty` to change the `tty?` flags. (Sergio Gil Pérez de la Manga, #1459) | |||
* Allow `satisfy` to match block expectations return value. (Phil Pirozhkov, #1477) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Allow `satisfy` to match block expectations return value. (Phil Pirozhkov, #1477) | |
* Improve the `satisfy` matcher to allow assertations on an `expect { ... }` return value. | |
(Phil Pirozhkov, #1477) |
@@ -1,3 +1,19 @@ | |||
RSpec.shared_examples "an RSpec value-only matcher" do |options| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this technically makes it more consistent but it causes a lot of churn, I'm leaning towards preferring inverting this so that "an RSpec value matcher"
is the "value only" specs and the opposite is named something else, or even make these optional specs part of one group like above.
end | ||
end | ||
|
||
pending "allows a matcher as an argument" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not introduce pending specs unless its for something version specific, what needs to be done to make this work?
end | ||
end | ||
|
||
describe "composed usage" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should follow on from the example group description
describe "composed usage" do | |
describe "when composed with other matchers" do |
@match_results[inner] = inner.matches?(inner_matcher_block(args)) | ||
p = Proc.new { |*args2| | ||
returned = inner_matcher_block(args).call(*args2) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to take care of ruby2 keywords (e.g. marked as such, not having keywords itself) so that they get passed through, I'm also a bit nervous about returned
why isn't it just implict from the assignment?
(A bit of a philosophical note, as I was tagged...) I can’t say that I am fond of this solution. The original idea for The solution with This is a choice that is questioned by some, but it allows to build powerful, combinable checks, which very clearly report “what went wrong” when the specs are red, able to produce nice diffs depending on the context of the check and so on. Even the original May I ask why the original |
Migrated to the monorepo as rspec/rspec#150 |
fixes rspec/rspec#91
idea #805 (comment)