DZone Snippets: TDD code

.autotest file

caffo () — Fri, 23 Mar 2007 10:31:52 GMT



require 'autotest/redgreen'

require 'autotest/timestamp'

#require 'autotest/growl'



#require 'autotest/html_report'

#require 'autotest/kdenotify'

#require 'autotest/menu'

#require 'autotest/pretty'

#require 'autotest/snarl'



# Sort-of from http://blog.labratz.net/articles/2006/09/13/growl-autotest-rails-with-zentest-3-4-0

def growl(title, msg, pri=0, stick="", image="")

  image_arg = (!image.empty?) ? "--image #{image}" : ""

  system "growlnotify -n autotest #{image_arg} -p #{pri} -m #{msg.inspect} #{title} #{stick}" 

end



Autotest.add_hook :red do |at|

  growl("Tests Failed", "#{at.files_to_test.size} tests failed", 2, "", "/Applications/Mail.app/Contents/Resources/Caution.tiff")

end



Autotest.add_hook :green do |at|

  growl("Tests Passed", "All tests passed", -2, "", "/Applications/Mail.app/Contents/Resources/certificate.tiff") #if at.tainted

end

Tagging Your Test Cases

MattScilipoti (Matt Scilipoti) — Thu, 21 Sep 2006 08:59:06 GMT

From http://www.railtie.net/articles/2006/09/17/tagging-your-test-cases:
Here's a quick way to follow your tests a little more closely in your test.log. In your test setup, add the following line:



def setup

  RAILS_DEFAULT_LOGGER.debug "\n\e[0;31mRUNNING TEST CASE: #{name}\e[m\n"

end

Rake's missing_method found!

MattScilipoti (Matt Scilipoti) — Fri, 28 Jul 2006 18:21:06 GMT

From http://newbieonrails.topfunky.com/articles/2006/07/28/foscon-and-living-dangerously-with-rake:
Updated from : http://mentalized.net/journal/2006/07/28/run_specific_tests_via_rake/

If you define a rule with an empty string, you can catch any task that hasn’t been defined elsewhere. This makes it easy to dynamically create rake tasks. Essentially, this is method_missing for rake!



rule "" do |t|

  t.name 

  # ... do something with the name of the task  

end

I experimented by writing a rule that will take a task with the format of controllername_testname and automatically run a single test from the relevant functional or unit test.



##

# Run a single test in Rails.

#

#   rake blogs_list

#   => Runs test_list for BlogsController (functional test)

#

#   rake blog_create

#   => Runs test_create for BlogTest (unit test)



rule "" do |t|

  if /(.*)_([^.]+)$/.match(t.name)

    file_name = $1

    test_name = $2

    if File.exist?("test/unit/#{file_name}_test.rb")

      file_name = "unit/#{file_name}_test.rb" 

    elsif File.exist?("test/functional/#{file_name}_controller_test.rb")

      file_name = "functional/#{file_name}_controller_test.rb" 

    else

      raise "No file found for #{file_name}" 

    end

    sh "ruby -Ilib:test test/#{file_name} -n /^test_#{test_name}/" 

  end

end

Update from : http://mentalized.net/journal/2006/07/28/run_specific_tests_via_rake/
This modified version uses a different syntax (rake test:foo:bar instead rake foo_bar) and regex matching for test names.

Usage



$ rake test:blog

=> Runs the full BlogTest unit test



$ rake test:blog:create

=> Runs the tests matching /create/ in the BlogTest unit test



$ rake test:blog_controller

=> Runs all tests in the BlogControllerTest functional test



$ rake test:blog_controller:create

=> Runs the tests matching /create/ in the BlogControllerTest functional test

Code



# Run specific tests or test files

# 

# rake test:blog

# => Runs the full BlogTest unit test

# 

# rake test:blog:create

# => Runs the tests matching /create/ in the BlogTest unit test

# 

# rake test:blog_controller

# => Runs all tests in the BlogControllerTest functional test

# 

# rake test:blog_controller

# => Runs the tests matching /create/ in the BlogControllerTest functional test	

rule "" do |t|

  # test:file:method

  if /test:(.*)(:([^.]+))?$/.match(t.name)

    arguments = t.name.split(":")[1..-1]

    file_name = arguments.first

    test_name = arguments[1..-1] 

    

    if File.exist?("test/unit/#{file_name}_test.rb")

      run_file_name = "unit/#{file_name}_test.rb" 

    elsif File.exist?("test/functional/#{file_name}_test.rb")

      run_file_name = "functional/#{file_name}_test.rb" 

    end

    

    sh "ruby -Ilib:test test/#{run_file_name} -n /#{test_name}/" 

  end

end

Do whatever you want with the above code, it’s yours now.

ClassLibrary Projects and App.config

MattScilipoti (Matt Scilipoti) — Mon, 17 Jul 2006 18:38:10 GMT

This snippet comes from Jamie Cansdale at TestDriven.net (http://weblogs.asp.net/nunitaddin/archive/2006/06/07/ClassLibrary-Projects-and-App.config.aspx)

In Visual Studio .NET 2003 if you want you unit tests to use an app config file you need to ensure a config file exists with the same path as your test assembly but ending with '.config'. Life has improved a bit with Visual Studio 2005 as it will automatically copy any 'App.config' file to the correct place even for ClassLibrary projects. You can achieve the same affect in VS2003 by using the following post-build event:



copy "$(ProjectDir)App.config" "$(TargetPath).config"

making functional test failures readable

MattScilipoti (Matt Scilipoti) — Fri, 24 Mar 2006 09:03:01 GMT

making functional test failures readable

By zenspider on Rails

Tired of your rails functional test failures being completely unreadable? I'm not terribly fond of rails' assert_tag but it is better than nothing. However, I never like to read something like the following:



expected tag, but no tag found matching {:attributes=>{:action=>"/admin/themes/update/1"}, :tag=>"form"} in:

"".

Ugh! It just does nothing to help you and since it isn't expressed as a diff, unit_diff is no help in this arena. I have however figured out how to make it much more manageable with the following snippets:



class ApplicationController < ActionController::Base

 def initialize(testing=false)

 super()

 self.class.layout(nil) if testing

 end

 [...]

end



and then in your functional tests:



def setup

 @controller = MyController.new(true)

 [...]

end

Now your failures contain just the content from the page:



expected tag, but no tag found matching {:attributes=>{:action=>"/admin/themes/update/1"}, :tag=>"form"} in:

"\n\n Name: Blue
\n Folder: blue
\n Description: A Plain blue theme
\n Masthead: Blue
\n Editor: n/a
\n
\n\nCancel Editing\n".

Partial Mock Object or mocking an instance of an object.

MattScilipoti (Matt Scilipoti) — Sun, 12 Mar 2006 09:33:38 GMT

From: http://www.karmiccoding.com/articles/2006/03/11/under-the-hood-with-ruby-partial-mock-objects-for-unit-testing

"What happens though, if you want to override a class in an instance of an object, and not all of its kind? Typically you would define a mock object, and create an instance of it. But, in Ruby there is an easier and faster way that doesn’t involve writing a different mock class for each different scenario – and it is made possible by the singleton class. This clever bit of ruby hackery lets you override the behaviour of a single instance of a class, creating what I’ve decided to call a partial mock object. To demonstrate, I’ve written a small method called override_method which will override the behaviour of the specified method in the passed object, like so:



# Overrides the method +method_name+ in +obj+ with the passed block

def override_method(obj, method_name, &block)

  # Get the singleton class/eigenclass for 'obj'

  klass = class <

  # Undefine the old method (using 'send' since 'undef_method' is protected)

  klass.send(:undef_method, method_name)



  # Create the new method

  klass.send(:define_method, method_name, block)

end



# Just an example class

class Foo 

  def do_stuff

    "I'm okay!" 

  end

end



# Test code

list = []

5.times { list.push(Foo.new) }



# We override the method here!

override_method(list.first, :do_stuff) { "I'm NOT okay!" }



list.each_with_index { |f, i| puts "(#{i}) #{f.do_stuff}" }



Outputs:

(0) I'm NOT okay!

(1) I'm okay!

(2) I'm okay!

(3) I'm okay!

(4) I'm okay!

As you can see, only the first object in the array’s behaviour has been changed – the rest have remained untouched. Because of this, you can embed these partial dynamic mock objects deeply into your code without the need to specially instantiate a mock object deep in your code, or writing a ‘clever mock’ to only trigger the determined behaviour in certain objects.

Where this code comes in really handy is when you need an object to raise a difficult to simulate exception (like a disk full error) on a certain method to test your error handling – simply call override_method and pass in a call to raise and voila! Dynamic partial mock objects on the fly!"