On Mar 10, 9:50 am, David Pfeffer <[email protected]> wrote:
> I've been trying out the *expect* syntax instead of the *should* syntax and
> ran into some interesting problems. So you don't have to worry about
> implementation details, I have a working example of the *should* syntax
> test above the *expect* syntax test for comparison. The *should* syntax
> tests pass and find all the matchers / helper methods. Conversely, the *
> expect* syntax tests do not work or require all the comparison logic to be
> inside the quotes. Any ideas what I'm doing wrong?
>
> it "takes a properly formed coin set array as a string" do
> CoinChanger.new("1,5,10,25,100").should be_valid
> # This passes.
> #expect { CoinChanger.new("1,5,10,25,100")}.to be_valid
> # This does not pass. It throws an error that the "valid?" method
> cannot be found.
> #expect { CoinChanger.new("1,5,10,25,100").valid? }.to be_true
> # This passes but does not use the matcher.
> end
>
> it "stores the coin set in descending order" do
> CoinChanger.new([1,5,10,25,100]).coin_set.should eq([100,25,10,5,1])
> # This passes.
> #expect { CoinChanger.new([1,5,10,25,100]).coin_set ==
> [100,25,10,5,1]}.to be_true # This passes but does not use the
> matcher.
>
> #expect { CoinChanger.new([1,5,10,25,100]).coin_set }.to
> eq([100,25,10,5,1]) # This fails but should pass.
> end
>
> it "does not return the wrong amount of change" do
> @changer.change(1).should_not eq [0,0,0,0,2]
> # Test passes
> expect { @changer.change(1) == [0,0,0,0,2] }.to be_false
> # Test fails but should pass
> expect { @changer.change(1) == [0,0,0,0,2] }.to be_true
> # Test passes but should fail
> end
>
> Note: I have intentionally commented out the *expect* syntax examples above
> since they are not working as expected... no pun intended :)
>
> Thanks,
The problem is that in each case here you are passing a *block* to
`expect` rather than a *value*. You can pass a block to `expect`, but
then the expectation is set on the block itself, and not on the value
the block returns. This is by design, so that `expect` can support
these matchers, which could never work on static values:
* change
* raise_error
* throw_symbol
* yield_control
* yield_with_args
* yield_with_no_args
* yield_with_successive_args
Each of these things is something that happens while executing a block
of code, and they need to operate on a block to work.
Taking one of your examples:
expect { CoinChanger.new("1,5,10,25,100") }.to be_valid
If you were to translate this back to the old `should` syntax, this is
equivalent to:
lambda { CoinChanger.new("1,5,10,25,100") }.should be_valid
What you really want is to pass the value directly to `expect` rather
than wrapping it in a block:
expect(CoinChanger.new("1,5,10,25,100")).to be_valid
HTH,
Myron
--
You received this message because you are subscribed to the Google Groups
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.