New Features of Test::Unit 2.0 Daniel Berger Ruby, C, Perl Win32Utils SysUtils Shards Sapphire

Test::Unit now a gem Maintained by Kouhei Sutou gem install test-unit

Maintained by Kouhei Sutou

gem install test-unit

I Do Not Know RSpec Shoulda If your favorite testing framework already supports the features I discuss, great If not, perhaps you’ll want to borrow them

RSpec

Shoulda

If your favorite testing framework already supports the features I discuss, great

If not, perhaps you’ll want to borrow them

How to use Test::Unit 2.x require ‘rubygems’ gem ‘test-unit’ require ‘test/unit’

require ‘rubygems’

gem ‘test-unit’

require ‘test/unit’

New Assertions assert_true assert_false assert_boolean

assert_true

assert_false

assert_boolean

assert_true assert_true(condition) Same as: assert_equal(true, condition) assert(condition)

assert_false assert_false(condition) Same as: assert_equal(false, condition)

assert_boolean assert_boolean(result) Same as: assert_equal(true, [true, false].include?(result))

Wow Ooh, aah.

New stuff to use within tests omit() omit_if() omit_unless() pend() notify()

omit()

omit_if()

omit_unless()

pend()

notify()

omit, omit_if, omit_unless Used to skip tests entirely Or in specific circumstances

Omit Examples class TC_MyTest < Test::Unit::TestCase def test_alpha omit(&quot;Buggy library. Skip&quot;) # never reach past here assert_true(1 == 1) end def test_beta omit_if(File::ALT_SEPARATOR, &quot;Skipping test on MS Windows&quot;) # Won’t run this test on MS Windows (or VMS) assert_true(1 == 1) end def test_gamma omit_unless(File::ALT_SEPARATOR, &quot;Only run on MS Windows&quot;) # Won’t run this test except on MS Windows assert_true(1 == 1) end end

Output 1) Omission: Buggy library. Skip test_alpha(TC_MyTest) omit_examples.rb:7:in `test_alpha' 2) Omission: Skipping test on MS Windows test_beta(TC_MyTest) omit_examples.rb:12:in `test_beta' 3 tests, 1 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications Only 1 assertion ran, the other two were skipped

pend The Test::Unit version of a TODO item But better, because a TODO in code is easily forgotten, but a pending test will annoy you into completing it.

The Test::Unit version of a TODO item

But better, because a TODO in code is easily forgotten, but a pending test will annoy you into completing it.

pend example class TC_MyTest < Test::Unit::TestCase def setup @obj = MyClass.new end def test_alpha pend(&quot;The 'alpha' function hasn't been implemented yet&quot;) assert_true(@obj.alpha) end end 1) Pending: The 'alpha' function hasn't been implemented yet test_alpha(TC_MyTest) pend_example.rb:13:in `test_alpha' 1 tests, 0 assertions, 0 failures, 0 errors, 1 pendings, 0 omissions, 0 notifications

notify A notification within your test Unlike typical stdout, tracked by Test::Unit as its own entity Possibly useful as a test debugger (?)

A notification within your test

Unlike typical stdout, tracked by Test::Unit as its own entity

Possibly useful as a test debugger (?)

notify example class TC_MyTest < Test::Unit::TestCase def test_alpha notify(&quot;starting the alpha test&quot;) assert_true(1 == 1) notify(&quot;finished the alpha test&quot;) end end 1) Notification: starting the alpha test test_alpha(TC_MyTest) notify_example.rb:7:in `test_alpha' 2) Notification: finished the alpha test test_alpha(TC_MyTest) notify_example.rb:9:in `test_alpha' 1 tests, 1 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 2 notifications

startup and shutdown Analogous to startup and teardown, except that they only run once per test case As opposed to once per test Oh, and they’re singleton methods Use for things you only need to do once, e.g. file generation, database connections, etc

Analogous to startup and teardown, except that they only run once per test case

As opposed to once per test

Oh, and they’re singleton methods

Use for things you only need to do once, e.g. file generation, database connections, etc

startup & shutdown example class TC_MyTest < Test::Unit::TestCase def self.startup @@file_name = File.join(Dir.pwd, 'my_test_file.txt') @@file_handle = File.open(@@file_name, 'w') end def test_file_path assert_respond_to(@@file_handle, :path) end def self.shutdown @@file_handle.close File.delete(@@file_name) end end Don’t forget the ‘self’

multiple setup & teardown You can have multiple setup and teardown methods with their own name Each setup runs in the order declared, before any tests are run Each teardown runs in reverse order declaration after all tests have run Useful for breaking out big chunks of setup and teardown code into their own, manageable pieces

You can have multiple setup and teardown methods with their own name

Each setup runs in the order declared, before any tests are run

Each teardown runs in reverse order declaration after all tests have run

Useful for breaking out big chunks of setup and teardown code into their own, manageable pieces

multiple setups class TC_MyTest < Test::Unit::TestCase def setup # first @standard = MyClass.new end setup # second def setup_alpha @alpha = MyClass.new end setup # third def setup_beta @beta = MyClass.new end def test_stuff assert_true(1 == 1) end end

multiple teardowns class TC_MyTest < Test::Unit::TestCase def test_stuff assert_true(1 == 1) end def teardown # last @standard = nil end teardown # second def teardown_alpha @alpha = nil end teardown # first def teardown_beta @beta = nil end end

Setup Attributes setup :before => :prepend Runs before default setup setup :before => :append Runs before default setup, but after before/prepend setup :after => :prepend Runs after default setup, but before after/append and custom setup methods setup :after => :append Runs after default setup and after custom setup methods

setup :before => :prepend

Runs before default setup

setup :before => :append

Runs before default setup, but after before/prepend

setup :after => :prepend

Runs after default setup, but before after/append and custom setup methods

setup :after => :append

Runs after default setup and after custom setup methods

Attribute ‘before’ class TC_MyTest < Test::Unit::TestCase def setup # Third puts &quot;In setup&quot; end setup # Fourth def setup_alpha puts &quot;In setup_alpha&quot; end setup :before => :prepend # First def setup_beta puts &quot;In setup_beta&quot; end setup :before => :append # Second def setup_gamma puts &quot;In setup_gamma&quot; end end

Quick Rules Summary setup :before => :prepend setup :before => :append setup (default) setup :after => :prepend setup (custom) setup :after => :append Get it? Got it? Good.

setup :before => :prepend

setup :before => :append

setup (default)

setup :after => :prepend

setup (custom)

setup :after => :append

Get it? Got it? Good.

Better Diff Output 1) Failure: test_string_diff(TC_MyTest) [diff_example.rb:7]: <&quot;weird&quot;> expected but was <&quot;wierd&quot;>. 1) Failure: test_string_diff(TC_MyTest) [diff_example.rb:7]: <&quot;weird&quot;> expected but was <&quot;wierd&quot;>. diff: - weird ? - + wierd ? + Old: New:

Priority Mode Adds a –priority-mode command line option If used, failed tests always repeat Tests that passed previously have a 50% chance of running Designed to reduce your test time Can be controlled with priority pragma

Adds a –priority-mode command line option

If used, failed tests always repeat

Tests that passed previously have a 50% chance of running

Designed to reduce your test time

Can be controlled with priority pragma

Sample Priority Output 1) Failure: test_one(TC_MyTest) [priority.rb:47]: <true> expected but was <false> 2) Failure: test_two(TC_MyTest) [priority.rb:51]: <true> expected but was <false> 7 tests, 7 assertions, 2 failures , 0 errors, 0 pendings, 0 omissions, 0 notifications 1) Failure: test_one(TC_MyTest) [priority.rb:47]: <true> expected but was <false> 2) Failure: test_two(TC_MyTest) [priority.rb:51]: <true> expected but was <false> 6 tests, 6 assertions, 2 failures , 0 errors, 0 pendings, 0 omissions, 0 notifications

Forcing a test priority :must def test_blah assert_true(1 == 1) end This test will always run, regardless of the “–priority-mode” switch.

Priority Modes must (i.e. always) important high normal low Never Not sure what the probabilities are, and it doesn’t matter.

must (i.e. always)

important

high

normal

low

Never

Not sure what the probabilities are, and it doesn’t matter.

Colorized Output On by default (bad) Disable with –no-use-color Doesn’t work on Windows (yet)

On by default (bad)

Disable with –no-use-color

Doesn’t work on Windows (yet)

Any questions?