similar to: slow tests on an established project...

On my current project I needed to create a stub that responded correctly to the id message. Here''s the change I put into my copy of head. Index: lib/mocha/mock_methods.rb =================================================================== --- lib/mocha/mock_methods.rb (revision 1114) +++ lib/mocha/mock_methods.rb (working copy) @@ -68,6 +68,7 @@ method_names =

I find that a lot of times I want to ensure a method gets called exactly once, for example when testing caching or eager loading. What does the list think of adding this little humane method to Mocha::Expectation? def once times(1) self end which means this: def test_should_only_grab_post_once_from_the_cache Post.expects(:get_cache).with(google_vs_yahoo.id).times(1)

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

I''ve finally managed to find some time to do some serious work on Mocha. There are some code snippets on my blog (http://blog.floehopper.org/articles/2007/04/12/preview-of-latest-mocha-changes) showing the new functionality available in trunk (revision 128). I don''t don''t know how many people out there are using trunk, but it would be great to get some feedback on these

Hi all, We just updated to the latest version of Mocha and now we''re seeing a lot of odd test failures. If this isn''t the appropriate place for a question like this, please let me know. Say I have code like this in a controller: DataMonitor.toggle_notification! And I mock it like this: DataMonitor.any_instance.stubs(:toggle_notification!) This would work fine with Mocha

I''ve just been tying my brain in knots looking at bug #8687 ( http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477 ). I''ve been (1) trying to work out whether there is anything logically wrong with Mocha''s existing behaviour and (2) whether Mocha should support the requested functionality. It all centres around the use of the

I''d like to create expectations on just portions of the arguments a function takes. For example, I want to verify that the a certain ActiveRecord association extension adds an order clause to the find options hash. Currently I simply check the entire argument structure, something like this def test_referring_journals_should_order_by_citation_count article =

Folks- With Rails 2.0.2, I''m seeing mocha failures where they did not fail with Rails 2.0.1 test_set_to_process_fail_in_transaction(FileRecordTest): NoMethodError: undefined method `ord'' for 63:Fixnum /home/wolpert/svn/rubylms/vendor/plugins/mocha/lib/mocha/class_method.rb:45:in `hidden_method''

We''re using Mocha stubs to stub out a slow-performing network request in a Test::Unit class. But naturally, we don''t want to stub it out in the few tests that actually verify the functionality of that network request. Is there a way to do the stub in "setup", but override it for the few tests that need the original functionality? (I realize that in this case, the

I was reading through the FlexMock docs and noticed the expectation method .mock, which returns the original mock associated with an expectation. It looks really handy for writing nice all-in-one mocks like: mock_user = mock(''User'').expects(:first_name).returns(''Jonah'').mock So I started playing around with mocha and found I could actually already do this!

Anyone know how to stub Kernel#open? I''m trying to mock/stub an open-uri call, but it doesn''t seem to like it. Here''s the test code, and the failures: body = File.open(File.dirname(__FILE__) + ''/../fixtures/google_search_california.html'').read

A number of people have had difficulties subscribing and/or sending messages to the existing mailing list. Also I have to spend quite a bit of time moderating spam and the mailman interface is pretty clunky. So I was contemplating setting a Google Group up instead. Does anyone have any objections? -- James. http://blog.floehopper.org http://tumble.floehopper.org

Hi, Are there any docs for combining parameter matchers, or some way to define optional parameters? I''m trying to match something like: .find( 42 ) || .find( 42, {:conditions=>nil,:includes=>nil} ) Or for that matter, 42 followed by nothing or anything... Halp? I''ve tried different nested combos with any_of/all_of/anything, but getting lost trying. --Andrew

I prefer to use rspec than test::unit for developing my apps. However I''ve found its mocking library to be pretty inflexible compared to Mocha. This isn''t really a surprise since rspec isn''t intended as a mocking framework, whereas Mocha is. So I''d like to play to both of their strengths and use rspec as my testing/specification framework and Mocha do to

I prefer to use rspec than test::unit for developing my apps. However I''ve found its mocking library to be pretty inflexible compared to Mocha. This isn''t really a surprise since rspec isn''t intended as a mocking framework, whereas Mocha is. So I''d like to play to both of their strengths and use rspec as my testing/specification framework and Mocha do to

Hi, I''ve been reading with interest the threads trying to integrate Mocha and Stubba with RSpec. So far, I''ve made the two changes in spec_helper.rb suggested, but discovered another one that neither of the archives mentions: If you use traditional mocking: object = mock or the stub shortcut : object = stub(:method => :result), you run into namespace conflicts with

Hi guys, I''m running mocha (0.3.2) against Rails core and just found an issue where the mock doesn''t go away after the test is run. For example: def test_reset_bang_doesn_reinstall_named_routes ActionController::Routing::Routes.named_routes.expects(:install).never @session.reset! end def test_zzz puts ActionController::Routing::Routes.named_routes.inspect

Hey all, I have a question with using mocha in my tests. In the same test file, I have two tests, <code> def test_a klass.any_instance.stubs(:method_name).returns("something") klass.new.method_name ... end def test_b ... klass.new.method_name ... end </code> where klass is some class when the tests run, test _a passes, but test_b had an error like this:

* Hamcrest-style parameter matchers * Values returned and exceptions raised on consecutive invocations * Yields on consecutive invocations * Multiple yields on single invocation * Invocation dispatch fixed * Deprecated returning result of a Proc -- James. http://blog.floehopper.org

We''ve been working with the ParameterMatchers (so cool!) but I don''t see a way to insure a method is called with no arguments. I imagined something like: user = mock(''User'') user.expects(:friends).with(nothing) Anyone run into this?