Unit testing idiom

ruby-talk
1

Hi all,

It's always bothered me having code and unit tests in different places - keeping unit tests near the code they are testing *has* to be a good thing, right?

Given the above, I stumbled on the following idiom:

$ cat testable.rb
module Test; module Unit; class TestCase; end; end; end

module Testable
   def test_case(&block)
     Class.new(Test::Unit::TestCase).module_eval &block
   end
end

$ cat builtin_tests.rb
require 'testable'

class MyWorkingClass
   extend Testable

   def foo(a,b)
     return a+b
   end

   test_case {
     def test_foo_null
       assert_equal 2, MyWorkingClass.new.foo(1,1)
     end
   }
end

if __FILE__ == $0
   puts MyWorkingClass.new.foo(1,1)
end

$ ruby builtin_tests.rb
2
$ testrb builtin_tests.rb
Loaded suite builtin_tests.rb
Started
.
Finished in 0.00095 seconds.

1 tests, 1 assertions, 0 failures, 0 errors
$

Just thought I'd share :slight_smile: Are there any drawbacks to this method that I haven't seen yet?

···

--
Alex

2

I don't know that I agree with your premise. While it might seem
convenient to combine tests with the artifacts they test, in general
I think that separating them is a good thing.

Having separate tests acts as a sort of double-entry bookkeeping
system. If they are combined there's the possbility of 'cooking the
books' either deliberately or unintentionally.

For simple things, such as trying something out, or demonstrating your
ruby-foo on posts here, combining the tests and code being tested
might be alright, but I think it's an idea best used in moderation.
For anything larger, I'd advocate for setting up a system for locating
the test code, such as the directory structure used by Rails.

···

On 6/13/07, Alex Young <alex@blackkettle.org> wrote:

Hi all,

It's always bothered me having code and unit tests in different places -
  keeping unit tests near the code they are testing *has* to be a good
thing, right?

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/