We''re encountering a failure with Mocha 0.5.6.
We had this expectation:
game_version.expects(:attributes=).with(:game_file =>
kind_of(GameFile), :game_id => @game.id)
This expectation was passing with 0.5.5, but fails with 0.5.6.
I added this test to parameter_matcher_acceptance_test.rb, which
passes in 0.5.5 and fails in 0.5.6
def test_should_match_nested_parameters
test_result = run_test do
mock = mock()
mock.expects(:method).with(:literal_key => kind_of(Integer))
mock.method(:literal_key => 1)
end
assert_passed(test_result)
end
Any insight?
I''m also seeing a problem. I haven''t researched it enough,
but here''s
what''s going on in a nutshell...
I have this line:
outfile.stubs(:each_line).times(2).returns(''1234512123\n'',''abcdefgxyz\n'')
and then the object ''outfile'' is passed in to another method
that
called ''each_line'' in a loop with result from the called being
''yield''ed... In a nutshell, like this
fwr.process_file(outfile) do |array|
validate_data(array)
end
I''m not sure exactly where the error is, but this code hasn''t
changed
in a long time, but with the latest mocha, broke. I''m still
researching what is actually broken, but I kinda hope that this bit of
debug is helpful...
On Jan 28, 2008 12:36 PM, Duncan Beevers <duncanbeevers at gmail.com>
wrote:> We''re encountering a failure with Mocha 0.5.6.
>
> We had this expectation:
>
> game_version.expects(:attributes=).with(:game_file =>
> kind_of(GameFile), :game_id => @game.id)
>
> This expectation was passing with 0.5.5, but fails with 0.5.6.
>
> I added this test to parameter_matcher_acceptance_test.rb, which
> passes in 0.5.5 and fails in 0.5.6
>
> def test_should_match_nested_parameters
> test_result = run_test do
> mock = mock()
> mock.expects(:method).with(:literal_key => kind_of(Integer))
> mock.method(:literal_key => 1)
> end
> assert_passed(test_result)
> end
>
> Any insight?
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>
--
Virtually, Ned Wolpert
http://www.codeheadsystems.com/blog/
"Settle thy studies, Faustus, and begin..." --Marlowe
So we cleared this up by making the kind_of matcher to return true
when tested for equality with an instance of the class it is supposed
to match on.
Diff is attached, the important bit is here in kind_of.rb:
def matches?(available_parameters)
parameter = available_parameters.shift
- parameter.kind_of?(@klass)
+ self == parameter
end
+
+ def ==(to_compare)
+ to_compare.kind_of?(@klass)
+ end
Feelings?
On Jan 28, 2008 11:36 AM, Duncan Beevers <duncanbeevers at gmail.com>
wrote:> We''re encountering a failure with Mocha 0.5.6.
>
> We had this expectation:
>
> game_version.expects(:attributes=).with(:game_file =>
> kind_of(GameFile), :game_id => @game.id)
>
> This expectation was passing with 0.5.5, but fails with 0.5.6.
>
> I added this test to parameter_matcher_acceptance_test.rb, which
> passes in 0.5.5 and fails in 0.5.6
>
> def test_should_match_nested_parameters
> test_result = run_test do
> mock = mock()
> mock.expects(:method).with(:literal_key => kind_of(Integer))
> mock.method(:literal_key => 1)
> end
> assert_passed(test_result)
> end
>
> Any insight?
>
On 28/01/2008, Duncan Beevers <duncanbeevers at gmail.com> wrote:> > We''re encountering a failure with Mocha 0.5.6. > > We had this expectation: > > game_version.expects(:attributes=).with(:game_file => > kind_of(GameFile), :game_id => @game.id) > > This expectation was passing with 0.5.5, but fails with 0.5.6. > > I added this test to parameter_matcher_acceptance_test.rb, which > passes in 0.5.5 and fails in 0.5.6 > > def test_should_match_nested_parameters > test_result = run_test do > mock = mock() > mock.expects(:method).with(:literal_key => kind_of(Integer)) > mock.method(:literal_key => 1) > end > assert_passed(test_result) > end > > Any insight? >Sorry. I previously explained this change when it was made in trunk [1]. I had intended to warn people again when the change was released, but I released v0.5.6 in a bit of a hurry to provide Ruby v1.9 compatibility and the change slipped out. I hadn''t realised people were using the matchers in this way. I think a better solution is to make the HasEntry parameter matcher (and friends) convert its key & value to parameter matchers using #to_matcher and to compare these using #matches? In this way you would be able to do something like... def test_should_match_nested_parameters test_result = run_test do mock = mock() mock.expects(:method).with(has_entry(:literal_key => kind_of(Integer))) mock.method(:literal_key => 1) end assert_passed(test_result) end I''ve checked in some changes in revision 245 of trunk if you want to try them out. Let me know if I''ve misunderstood or made a mistake. -- James. http://blog.floehopper.org http://tumble.floehopper.org [1] http://rubyforge.org/pipermail/mocha-developer/2007-November/000482.html
On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:> > I''m also seeing a problem. I haven''t researched it enough, but here''s > what''s going on in a nutshell... > > I have this line: > > outfile.stubs > (:each_line).times(2).returns(''1234512123\n'',''abcdefgxyz\n'') > > and then the object ''outfile'' is passed in to another method that > called ''each_line'' in a loop with result from the called being > ''yield''ed... In a nutshell, like this > > fwr.process_file(outfile) do |array| > validate_data(array) > end > > I''m not sure exactly where the error is, but this code hasn''t changed > in a long time, but with the latest mocha, broke. I''m still > researching what is actually broken, but I kinda hope that this bit of > debug is helpful... >It''s not obvious that this is the same error or bug. Can you give more details i.e. the simplest self-contained failing test (and code under test) you can write or (ideally) a failing acceptance test like Duncan did. Thanks. -- James. http://blog.floehopper.org http://tumble.floehopper.org
On 28/01/2008, Duncan Beevers <duncanbeevers at gmail.com> wrote:> > So we cleared this up by making the kind_of matcher to return true > when tested for equality with an instance of the class it is supposed > to match on. > > Diff is attached, the important bit is here in kind_of.rb: > > def matches?(available_parameters) > parameter = available_parameters.shift > - parameter.kind_of?(@klass) > + self == parameter > end > + > + def ==(to_compare) > + to_compare.kind_of?(@klass) > + end > > Feelings?Well done for finding a fix :-) The idea of the change to the parameter matchers interface that I mentioned above [1] is that a matcher can now match against an arbitrary number of parameters. In particular this is used to allow for constraints on optional parameters as seen in OptionalParameterMatcherAcceptanceTest, for example: def test_should_pass_if_all_required_and_optional_parameters_match_and_some_optional_parameters_are_supplied test_result = run_test do mock = mock() mock.expects(:method).with(1, 2, optionally(3, 4)) mock.method(1, 2, 3) end assert_passed(test_result) end The #==(object) method wasn''t really suitable for this, hence the change to use the #matches?(available_parameters) method. I hope this makes sense and I hope my previous suggestion of using the new improved has_entry matcher is satisfactory. The reference [1] is still worth a read as are the code examples it references. Thanks. -- James. http://blog.floehopper.org http://tumble.floehopper.org [1] http://rubyforge.org/pipermail/mocha-developer/2007-November/000482.html
I wasn''t sure that this was the same thing... but I did notice that it broke (or I should stay, stopped working as expected) in the last mocha release... I''m going to investigate this today and if I think there is a problem with Mocha, I''ll post a test-case. On Jan 28, 2008 5:03 PM, James Mead <jamesmead44 at gmail.com> wrote:> On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote: > > > > I''m also seeing a problem. I haven''t researched it enough, but here''s > > what''s going on in a nutshell... > > > > I have this line: > > > > outfile.stubs > > (:each_line).times(2).returns(''1234512123\n'',''abcdefgxyz\n'') > > > > and then the object ''outfile'' is passed in to another method that > > called ''each_line'' in a loop with result from the called being > > ''yield''ed... In a nutshell, like this > > > > fwr.process_file(outfile) do |array| > > validate_data(array) > > end > > > > I''m not sure exactly where the error is, but this code hasn''t changed > > in a long time, but with the latest mocha, broke. I''m still > > researching what is actually broken, but I kinda hope that this bit of > > debug is helpful... > > > > It''s not obvious that this is the same error or bug. > > Can you give more details i.e. the simplest self-contained failing test (and > code under test) you can write or (ideally) a failing acceptance test like > Duncan did. > > Thanks. > -- > James. > http://blog.floehopper.org > http://tumble.floehopper.org > > _______________________________________________ > mocha-developer mailing list > mocha-developer at rubyforge.org > http://rubyforge.org/mailman/listinfo/mocha-developer >-- Virtually, Ned Wolpert http://www.codeheadsystems.com/blog/ "Settle thy studies, Faustus, and begin..." --Marlowe
Ignore my ''claim of a bug''. :-) Turns out the test case was misusing mocha... and just needed to fix the test case. On Jan 29, 2008 8:22 AM, Ned Wolpert <ned.wolpert at gmail.com> wrote:> I wasn''t sure that this was the same thing... but I did notice that it > broke (or I should stay, stopped working as expected) in the last > mocha release... I''m going to investigate this today and if I think > there is a problem with Mocha, I''ll post a test-case. > > > On Jan 28, 2008 5:03 PM, James Mead <jamesmead44 at gmail.com> wrote: > > On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote: > > > > > > I''m also seeing a problem. I haven''t researched it enough, but here''s > > > what''s going on in a nutshell... > > > > > > I have this line: > > > > > > outfile.stubs > > > (:each_line).times(2).returns(''1234512123\n'',''abcdefgxyz\n'') > > > > > > and then the object ''outfile'' is passed in to another method that > > > called ''each_line'' in a loop with result from the called being > > > ''yield''ed... In a nutshell, like this > > > > > > fwr.process_file(outfile) do |array| > > > validate_data(array) > > > end > > > > > > I''m not sure exactly where the error is, but this code hasn''t changed > > > in a long time, but with the latest mocha, broke. I''m still > > > researching what is actually broken, but I kinda hope that this bit of > > > debug is helpful... > > > > > > > It''s not obvious that this is the same error or bug. > > > > Can you give more details i.e. the simplest self-contained failing test (and > > code under test) you can write or (ideally) a failing acceptance test like > > Duncan did. > > > > Thanks. > > -- > > James. > > http://blog.floehopper.org > > http://tumble.floehopper.org > > > > _______________________________________________ > > mocha-developer mailing list > > mocha-developer at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mocha-developer > > > > > > > -- > Virtually, Ned Wolpert > http://www.codeheadsystems.com/blog/ > > "Settle thy studies, Faustus, and begin..." --Marlowe >-- Virtually, Ned Wolpert http://www.codeheadsystems.com/blog/ "Settle thy studies, Faustus, and begin..." --Marlowe
On 29/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:> > I wasn''t sure that this was the same thing... but I did notice that it > broke (or I should stay, stopped working as expected) in the last > mocha release... I''m going to investigate this today and if I think > there is a problem with Mocha, I''ll post a test-case. >Thanks. -- James. http://blog.floehopper.org http://tumble.floehopper.org
On 29/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:> > Ignore my ''claim of a bug''. :-) Turns out the test case was misusing > mocha... and just needed to fix the test case. >Cool. Thanks for letting us know. -- James. http://blog.floehopper.org http://tumble.floehopper.org