From: Jim Weirich <jweirich@...>
Date: 2003-01-28T15:25:14+09:00
Subject: Re: Test::Unit -> order of tests?

On Mon, 2003-01-27 at 13:43, Michael Garriss wrote:
> Concider the following simple example code: 

[... code elided ...]

I might try something like this ...

-- START CODE ----------------------------------------------------------
class TC_DB_User < Test::Unit::TestCase

  DNS  = 'dbi:Pg:tiamat'
  USER = 'postgres'
  PASS = nil
  
  def setup
    @tdb = Tiamat::DB_User.new(DNS, USER, PASS)
  end

  def test_create
    assert ! @tdb.nil?, "Should not be null"
  end
  
  def test_create_drop
    check_create_table
    check_drop_table
  end

  def check_create_table
    @tdb.create_user_table
    assert table_is_created, "table should exist"
  end
  
  def check_drop_table
    @tdb.drop_user_table
    assert ! table_is_created, "table should not exist"
  end

  def table_is_created
    # True/False test that actually checks if the table is created.
  end
  
end
-- END CODE ----------------------------------------------------------

A couple of points...
    @tdb.created?
* It bothers me to see assertions in contionally executed code (rescue
  clauses in this case).  I like to see the assertions executed every
  time.  Of course, that means "assert false" is not a good idea. :-)

* test_create is usually the first test I write, just to get the object 
  created.  Initial condition tests can be added here.  If the 
  test_create stays this simple, it will usually get removed as the test
  matures.

* The create and drop are tested in separate methods, but run under the 
  same test method.  This assures that the are run in order.  Since 
  any method named "test_*" will be executed as a separate test, the 
  original version of this would execute the following sequence of 
  events ...

     connect Tiamat
     connect Tiamat
     create user table
     connect Tiamat
     create user table
     drop user table

  I'm guessing the two create operations is not what is desired. 

* When using assert (rather than assert_equal), it really helps to add 
  the string since it gets printed out if the assertion fails.  I used 
  to write asserts like this ...

    assert x.nil?, "X is nil"

  which read great in the code. It reads like a comment that says "I am 
  assserting that X is nil".  But when the assertion fails, the error
  message displayed would be something like ...

    ERROR: X is nil: ... yada, yada, yada

  which is misleading because the asserted failed because X was NOT nil.
  Changing the message to read the other way ...

    assert x.nil?, "X is not nil"

  ... made the code look funny.  I finally discovered that including the
  word "should" make it read fine from both perspectives ...

    assert x.nil?, "X should be nil"

    ERROR: X should be nil: ... yada, yada, yada

Ok, that last point has way too much verbage for such a simple idea.  I
think I'll stop while I'm ahead.

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)