Thanks to a hint by Chris Mear on the Ruby on Rails Mailinglist I had an idea how to add profiling my unittests. It’s a simple 3 step process and adds just 5 lines of code to your unittests:

Step 1:

require 'profiler'


Step 2:

 def setup
  # ...
  # your normal setup code
  # ...
  Profiler__::start_profile
 end


Step 2:

 def teardown
  Profiler__::stop_profile
  f=File::new("#{RAILS_ROOT}/log/profiler.#{name() + ' ' +
              Time.now.strftime('%Y-%m-%d %H:%M')}.log", 'w')
  Profiler__::print_profile(f)
  # ...
  # your normal teardown code
  # ...
 end


As you probably guessed from the code, this will log the profiling results into a file for each test. But beware: this is VERY SLOW! The tests I was profiling took 9s without profiling and 1267s with profiling… But slow profiling still beats no profiling

If you are looking for memory profiling, there is a nice article by Scott Laird on Memory leak profiling with Rails.

This tutorial shows how to use distributed ruby to connect a rails application with another ruby service not running inside Rails. Read the rest of this entry »

Evil folks and stupid users expose webapplications to requests no sane developer usually expects. To find methods that cannot cope with unexpected input I added a simple test to my current Ruby on Rails project. The test calls all public actions via all http actions and uses some dummy parameters. There are no assertions in this test, because I don’t know if an action should succeed or redirect. The only thing checked with this test is that the action does not fail.

def test_dummy_calls
  ac = ApplicationController.new
  @controller.public_methods.each do |action|
    unless ac.respond_to?(action)
      [:get, :post, :head, :put, :delete].each do |http_method|
        [nil, '', 'abc'*80, '-23', '123456789012345'].each do |param|
          method(http_method).call(action, :id => param)
        end
      end
    end
  end
end

Technorati Tags: ruby, rails, tests