search for: should_equ

...methods. Here''s what it allows: context "a mock" do specify "can stub! and mock the same message" do mock = mock("stubbing mock") mock.stub!(:msg).and_return(:stub_value) mock.should_receive(:msg).with(:arg).and_return(:mock_value) mock.msg.should_equal :stub_value mock.msg(:other_arg).should_equal :stub_value mock.msg(:arg).should_equal :mock_value mock.msg(:another_arg).should_equal :stub_value mock.msg(:yet_another_arg).should_equal :stub_value mock.msg.should_equal :stub_value end end Basically, the stub will be invoke...

There''s another quirk I wanted to bring up. It''s about the failure message with should_equal and should_be. x.should_equal 2 a.should_not_be nil When they fail they yield messages like: 1 should equal 2 nil should not be nil When I''m caught off guard, which can be often, these messages confuse me. 1 should equal 2? No it shouldn''t. nil should not be nil? But...

...RTANT NOTE: THIS RELEASE IS NOT 100% BACKWARDS COMPATIBLE TO 0.6.x This release changes the way RSpec handles equality. Previous releases tried to handle equality based on the way the words read, rather than the way ruby actually handles equality. So, with this release and going forward: * actual.should_equal(expected) will pass if actual.equal?(expected) returns true * actual.should_eql(expected) will pass if actual.eql?(expected) returns true * actual.should == expected will pass if actual == expected) returns true At the high level, eql? implies equivalence, while equal? implies object identity. F...

This page has some typos in the forth grey box http://rspec.rubyforge.org/tutorials/stack_04.html "should_equal" should be "should ==" and "should_not_be_empty" should be "should_not be_empty" this causes some spec to fail By the way, this is my first mail to the list, so Hi everybody !!

...sense, but what about this? http://rspec.rubyforge.org/svn/branches/dogfood/spec/spec/mocks/mock_spec.rb specify "should use a list of return values for successive calls" do @mock.should_receive(:multi_call).twice.with(:no_args).and_return([8, 12]) @mock.multi_call.should_equal 8 @mock.multi_call.should_equal 12 @mock.__verify end Any feedback on how to properly test this is much appreciated. Thanks, Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080305/7...

I''m trying out rspec_on_rails with a very simple test: ... specify "product name should be ''test''" do Product.find( :all ).first.name.should_equal ''test'' end ... with this fixture: first: id: 1 name: test When I run it: .F 1) ''Given a generated product_spec.rb with fixtures loaded product name should be test'' FAILED "test" should equal "test" ./spec/models/product_spec.rb:12...

As things stand now, the following will all pass: true.should_be true "true".should_be true "false".should_be true 3.should_be true etc My feeling is that "should_be true" should only pass if it returns boolean true even though ruby says that non-nil/non-false is true. Anybody else? David

...tation. This would also give us a single expectations module that we add to Object, providing several benefits including: # more clarity in the API # a place to put meaningful rdoc # a potential formal plugin point 2. Change should_be to ONLY handle arbitrary predicates (not serve as an alias for should_equal): subject.should_be :empty => passes if subject.empty? subject.should_be :instance_of, SomeClass => passes if subject.instance_of? SomeClass etc... In my opinion (feel free to disagree), this actually makes these examples more readable. Consider these two: @bdd_framework.should_be_adopte...

...custom function. Ruby solutions tend to be much more elegant than that! Now here''s my RSpec_Watir solution, to log into a site: snapshot() @browser.should_contain("login") @browser.text_field(:id, ''login'').should_exist @browser.ie.document.activeElement.name.should_equal(''login'') # .because login field should have the focus Those lines violate the Systir principles; they use parens () and variables and state. They use a comment instead of an assertion documentation string. RSpec has gone a long way towards producing readable sentences - "...

...tive spec - is this better or worse? specify "should prefetch the future residuals" do # TODO: get rid of evil state testing residuals = @derivatives_by_id[26149].instance_variable_get ("@cap_future_residuals") @derivatives_by_id[26149].cap_future_residuals.should_equal residuals end Thanks for any advice Ashley

...tation. This would also give us a single expectations module that we add to Object, providing several benefits including: # more clarity in the API # a place to put meaningful rdoc # a potential formal plugin point 2. Change should_be to ONLY handle arbitrary predicates (not serve as an alias for should_equal): subject.should_be :empty => passes if subject.empty? subject.should_be :instance_of, SomeClass => passes if subject.instance_of? SomeClass etc... In my opinion (feel free to disagree), this actually makes these examples more readable. Consider these two: @bdd_framework.should_be_adopte...

...et<br> &nbsp;&nbsp;&nbsp; end<br> &nbsp;&nbsp;&nbsp; specify "should assign the found #{klass} for the view" do<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; do_get<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assigns(sym).should_equal @mock<br> &nbsp;&nbsp;&nbsp; end<br> &nbsp; end<br> end<br> <br> restful_edit_specs(:assessments)<br> <br> </tt>This all works fine when defined in the xx_controller_spec.rb file.<br> <br> But if I move the exact same cod...

Mike Williams contributed a patch to support arbitrary comparisons. This is now in the trunk and will be part of the next release. So you will now be able to do this: result.should_be < 5 result.should_be >= 7 It also supports alternate syntax for should_be, should_match result.should == 3 result.should =~ /regex/ Personally, I prefer should_be and should_match in these cases, as I think

...your own peril!) == rspec-0.9 * Will remove all of the old syntax. ======================================= Here are some answers to some questions that some of you may have: == What is changing? All of the should_xyz methods will be losing an underscore and gaining a space: #before actual.should_equal(expected) actual.should_not_equal(expected) #after actual.should equal(expected) actual.should_not equal(expected) #equal, in this example, is a method that returns an expectation matcher, which Ruby passes to #should, which then interacts with the matcher to evaluate whether or not the...

We''d like to get some feedback on RSpec 0.9 before we start pushing out releases via Rubyforge''s gem server and update the website. We have therefore made the first beta of 0.9 available - both prepackaged and tagged in subversion (see below). RSpec 0.9 introduces a new API for expectations, which essentially means that your underscores go away (there has been other discussions

...d eql.tmSnippet RSpec.tmbundle/Snippets/should_be.tmSnippet RSpec.tmbundle/Snippets/should_be_a_kind_of.tmSnippet RSpec.tmbundle/Snippets/should_be_an_instance_of.tmSnippet RSpec.tmbundle/Snippets/should_be_close.tmSnippet RSpec.tmbundle/Snippets/should_be_redirect.tmSnippet RSpec.tmbundle/Snippets/should_equal.tmSnippet RSpec.tmbundle/Snippets/should_have.tmSnippet RSpec.tmbundle/Snippets/should_have_at_least.tmSnippet RSpec.tmbundle/Snippets/should_have_at_most.tmSnippet RSpec.tmbundle/Snippets/should_have_records.tmSnippet RSpec.tmbundle/Snippets/should_include.tmSnippet RSpec.tmbundle/Snippets/shoul...