On Apr 29, 2010, at 09:12, caleb clausen wrote:

> Issue #3219 has been updated by caleb clausen.
>=20
> It is all too easy to write assert(foo, bar) when you meant to write =
assert_equal(foo, bar). I have made the same mistake myself a number of =
times. Usually, no error will result because assert allows an optional =
second parameter (an alternate String to be printed when the assertion =
fails).=20

I don't see how you could have this problem if you're following a red, =
green, refactor type discipline.  If the test passed when you forgot to =
add _equal you should immediately know you did it wrong because it =
should have failed.  How can you trust any of your tests if you haven't =
ensured they fail when something is wrong?

> I'd suggest that a better way to detect this problem is for assert to =
fail if a non-String is passed as the second parameter. This won't =
detect all cases of using assert when you meant assert_equal, but it =
should catch at lest 90%.

Why should I have to call #to_s manually when I can pass an object that =
will print something useful for me?

$ cat t.rb=20
require 'minitest/autorun'

class TestAssert < MiniTest::Unit::TestCase

  def test_assert
    o =3D Object.new
    def o.to_s() "something useful" end

    assert false, o
  end

end
$ ruby19 t.rb=20
Loaded suite t
Started
F
Finished in 0.000645 seconds.

  1) Failure:
test_assert(TestAssert) [t.rb:9]:
something useful

1 tests, 1 assertions, 1 failures, 0 errors, 0 skips

Test run options: --seed 42229