Floehopper

  $ script/plugin install svn://rubyforge.org/var/svn/mocha/trunk

Posted in mocha_release | Tags expectation, fixtures, mock, mocking, plugin, rails, ruby, stub, stubbing, test, testing, verify | 14 comments

Comments

1. nukeedit
   Mario Aquino said 3 days later:
   

   James,

   I have spent the day trying to get a test working using your Mocha library. I have adapted the auto_mock_acceptance_test by creating a simple Rails app with a Product model and a Sale model. Product declares a “has_many” relationship with Sale and Sale declares a “belongs_to” to Product, otherwise the code is identical to what you have in the acceptance test. The problem I am unable to deal with cleanly is that the calls to the ActiveRecord API (“has_many” and “belongs_to”) are causing the auto verify to fail (Unexpected message :has_many(:sales)). How do you deal with mocking calls to class methods executed when the class under test is loaded via ‘require’? I have tried adding “product.expects(:has_many).with(:sales)” essentially after the fact (after I create a new Product), but no luck.

   —Mario

2. nukeedit
   James Mead said 3 days later:
   

   I’m sorry Mario. As I mention in the README,

   “AutoMocha is more experimental and is at an earlier stage of development.”

   There are some issues with using AutoMocha in a Rails project, not least all the autoloading of classes that goes on. I have some potential solutions, but nothing committed to subversion yet.

   Although it probably won’t get you any further, the way I get round the problem you are describing is to require the product.rb file from within setup and set up expectations on the class itself. Something like…

     def setup
       unless @loaded then
         Product.expects(:has_many).with(:sales)
         @loaded = require File.dirname(__FILE__) + '/../../app/models/product.rb'
       end
     end

   What are you trying to do? Have you tried using Mocha & Stubba? We are actively using these on Rails projects and they seem pretty robust. Let me know if I can help.

3. nukeedit
   Mario Aquino said 3 days later:
   

   I can get my test to work with either Stubba or AutoMocha if I allow the tests to run piggy-backed on the Rails test_helper:

   require File.dirname(__FILE__) + '/../test_helper'
   require 'stubba'
   
   class ProductTest < Test::Unit::TestCase
     def test_should_find_sales_for_this_product_which_exceeded_specified_price
       cheap_order = Mocha::Mock.new
       cheap_order.expects(:price).returns(5)
       expensive_order = Mocha::Mock.new
       expensive_order.expects(:price).returns(15)
       orders = [cheap_order, expensive_order]
       product = Product.new
       product.stubs(:sales).returns(orders)
       assert_equal [expensive_order], product.sales_with_price_exceeding(10)
     end
   end

   As above, the test passes successfully. However, the test is also executing all of the Rails db-interation code (because of the test_helper); Stubba intercepts the ’:sales’ call but otherwise Rails code is getting a connection to the running db and going through all the steps to interact with the MySQL backend. I would prefer to run the tests in isolation from the database so I tried removing the require that adds the ‘test_helper’ and adding any missing requires (I also turned off my db server to prove that it isn’t really being called during successful test execution) but so far all my efforts have ended in “ActiveRecord::ConnectionNotEstablished” error messages. Is it possible to run fully stubbed-out unit tests against model classes without a running database or am I missing something?

   Thanks in advance for taking time to read this.

4. nukeedit
   James Mead said 3 days later:
   

   I think there might be a bit of confusion here…

   Mocha & Stubba are designed to work in conjunction with each other and are known to work with Rails. However, neither of these explicitly stops all access to the database. Mocha & Stubba are designed to be used with the Rails test_helper.

   AutoMocha is a different library which starts from the idea that a unit test should only test a single class. It is some way from being useable. It’s designed not to be used with the Rails test_helper. I suggest you don’t use it for now.

   I suspect there are only two places in your test which are hitting the database. If you want to avoid even this very limited access to the database (which I applaud)...

   1. By default, transactional fixtures are switched on which will mean that a “BEGIN” statement will be executed against the database connection and a “ROLLBACK” at the end. You can switch this off as follows…

     class ProductTest < Test::Unit::TestCase
   
     self.use_transactional_fixtures = false
   
     def test_stuff
       # stuff
     end
   
   end

   2. ActiveRecord regularly calls the Base#columns method which results in a “SHOW FIELDS FROM products” being executed. You can stub this out as follows…

     def test_should_find_sales_for_this_product_which_exceeded_specified_price
       # stuff
       Product.stubs(:columns).returns([]) # add this before doing anything with Product class
       product = Product.new
     end

   However if you want the Product attribute accessors to be available, you’ll need to return the correct array of ActiveRecord::ConnectionAdapters::Column objects.

   One last thing – if you require ‘mocha’ as well as ‘stubba’ (which is what the Rails plugin does), you can simplify your test a bit…

     require File.dirname(__FILE__) + '/../test_helper'
     require 'mocha'
     require 'stubba'
   
     class ProductTest < Test::Unit::TestCase
       def test_should_find_sales_for_this_product_which_exceeded_specified_price
         cheap_order = stub(:price => 5)
         expensive_order = stub(:price => 15)
         orders = [cheap_order, expensive_order]
         product = Product.new
         product.stubs(:sales).returns(orders)
         assert_equal [expensive_order], product.sales_with_price_exceeding(10)
       end
     end

   This article might be useful in ensuring your tests never touch the database.

   This article helps discriminate between when to mock and when to stub.

5. nukeedit
   Mario Aquino said 4 days later:
   

   Hi James,

   I will do some experimenting to find a way to isolate active record code from what I am trying to test in the model. Thanks for your advice above.

   —Mario

6. nukeedit
   MattyJ said 7 days later:
   

   Hi there, I installed the Rails plugin, but I can’t work out what this does to environment.rb.

   The problem is that environment.rb includes a “require_dependency” line, which seemingly doesn’t get included anymore.

   So, is environment.rb totally ignored with Mocha installed?

   or is something else going wrong?

7. nukeedit
   James Mead said 7 days later:
   

   MattyJ: The Mocha plugin should not affect what gets executed in environment.rb. The plugin is loaded using the standard plugin loading during Rails::Initializer.run called from environment.rb. Amongst other things, this call evaluates the plugin’s init.rb file. If in the test environment, Mocha’s init.rb simply requires the Rails ‘test_help’ file which sets up Rails specific Test::Unit stuff and then requires the Mocha libraries.

   Can you be a bit more explicit about what is going wrong? Is it a standard part of Rails environment.rb which is not working or something you have added? What specifically is going wrong e.g. do you have a stack trace?

   Please leave an email address in another comment and I’ll contact you directly. Alternatively you can contact me on this mailing list.

8. nukeedit
   MattyJ said 7 days later:
   

   We have a custom ‘Validations’ module, included at the end of environment.rb

   "# Include your application configuration below require_dependency 'validations'"

   It works whenever i delete the Mocha directory.

   anyway, thanks for your help

   C:/silly/config/../vendor/rails/activerecord/lib/active_record/base.rb:11
   29:in `method_missing': undefined method `validates_password_strength' for Baddie:Class (NoMethodError)
           from C:/silly/config/../app/models/baddie.rb:90
           from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
           from C:/silly/config/../vendor/rails/activerecord/lib/../../activ
   esupport/lib/active_support/dependencies.rb:147:in `require'
           from C:/silly/config/../vendor/rails/activerecord/lib/../../activ
   esupport/lib/active_support/dependencies.rb:65:in `require_or_load'
           from C:/silly/config/../vendor/rails/activerecord/lib/../../activ
   esupport/lib/active_support/dependencies.rb:30:in `depend_on'
           from C:/silly/config/../vendor/rails/activerecord/lib/../../activ
   esupport/lib/active_support/dependencies.rb:85:in `require_dependency'
           from C:/silly/config/../lib/login_system.rb:1
           from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
            ... 19 levels...
           from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
           from ./test/unit/../test_helper.rb:2
           from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
           from test/unit/silly_test.rb:1

9. nukeedit
   James Mead said 7 days later:
   

   MattyJ: Not sure what’s going on here – if you send me the following files, I’ll try to look into it…

   config/environment.rb
   test/test_helper.rb
   test/unit/silly_test.rb

   and the file where your custom validation module is defined.

   Can you do this via the mailing list or using something like pastie so we don’t clutter up the comments too much.

10. nukeedit
    Ed Howland said 11 days later:
    

    James,

    This library really works nicely. One issue that comes up (from reading Topfunky’s guide to plugins,) is in testing plugins that require AR type stuff. Since your plugin is designed to work within your larger Rails framework. How do you unit test independantly of the app you are plugging into?

    I just completed testing my plugin with both Stubba and Mocha. And since it does a little bit of reflection on AR models passed in, I could simulate that with stubs. I.e. the columns array just needs things like: model=mock() model.stubs(:columns).returns([stub(:primary=>true, :name=>‘id’), stub(:primar=>false, :name=>‘name’)])

    This simulates just enough of AR to satisfy my plugin’s methods.

    Thanks

11. nukeedit
    James Mead said 12 days later:
    

    Thanks for the positive feedback, although I’m not quite sure whether you’re asking me a question or telling me something! I think you’re telling me something.

    What you say sounds fine for detailed unit testing, although I would recommend you also have at least a few integration/acceptance tests that use real AR models. This would make sure for example that you catch any changes in AR’s API which you would miss if you were only stubbing.

12. nukeedit
    jps said 162 days later:
    

    If you ever see that you’re getting nil.[] errors while using the Mocha gem, simply get rid of it, and use this plugin.

13. nukeedit
    James Mead said 163 days later:
    

    jps: Can you tell me more about the errors you are seeing with the gem? It would probably be best to post to the mocha mailing list at http://rubyforge.org/mailman/listinfo/mocha-developer.

14. nukeedit
    Ilya Burkaltsev said 220 days later:
    

    TNX for perfect developer lib. It’s good :)

RSS feed for this post

Comments are disabled