New Features Of Test Unit 2.x
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

New Features Of Test Unit 2.x

on

  • 13,907 views

Review of the new features of Test::Unit 2.x for Ruby

Review of the new features of Test::Unit 2.x for Ruby

Statistics

Views

Total Views
13,907
Views on SlideShare
13,646
Embed Views
261

Actions

Likes
4
Downloads
38
Comments
0

3 Embeds 261

http://thopre.wordpress.com 219
http://www.slideshare.net 41
http://ig.gmodules.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

New Features Of Test Unit 2.x Presentation Transcript

  • 1. New Features of Test::Unit 2.0 Daniel Berger Ruby, C, Perl Win32Utils SysUtils Shards Sapphire
  • 2. Test::Unit now a gem
    • Maintained by Kouhei Sutou
    • gem install test-unit
  • 3. 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
  • 4. How to use Test::Unit 2.x
    • require ‘rubygems’
    • gem ‘test-unit’
    • require ‘test/unit’
  • 5. New Assertions
    • assert_true
    • assert_false
    • assert_boolean
  • 6. assert_true assert_true(condition) Same as: assert_equal(true, condition) assert(condition)
  • 7. assert_false assert_false(condition) Same as: assert_equal(false, condition)
  • 8. assert_boolean assert_boolean(result) Same as: assert_equal(true, [true, false].include?(result))
  • 9. Wow Ooh, aah.
  • 10. New stuff to use within tests
    • omit()
    • omit_if()
    • omit_unless()
    • pend()
    • notify()
  • 11. omit, omit_if, omit_unless Used to skip tests entirely Or in specific circumstances
  • 12. 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
  • 13. 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
  • 14. 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.
  • 15. 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
  • 16. notify
    • A notification within your test
    • Unlike typical stdout, tracked by Test::Unit as its own entity
    • Possibly useful as a test debugger (?)
  • 17. 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
  • 18. 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
  • 19. 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’
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Quick Rules Summary
    • setup :before => :prepend
    • setup :before => :append
    • setup (default)
    • setup :after => :prepend
    • setup (custom)
    • setup :after => :append
    • Get it? Got it? Good.
  • 26. 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:
  • 27. 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
  • 28. 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
  • 29. Forcing a test priority :must def test_blah assert_true(1 == 1) end This test will always run, regardless of the “–priority-mode” switch.
  • 30. Priority Modes
    • must (i.e. always)
    • important
    • high
    • normal
    • low
    • Never
    • Not sure what the probabilities are, and it doesn’t matter.
  • 31. Colorized Output
    • On by default (bad)
    • Disable with –no-use-color
    • Doesn’t work on Windows (yet)
  • 32. Any questions?