From: Ted Han Date: 2008-10-09T16:30:15+09:00 Subject: [ruby-core:19240] Re: refute_{equal, match, nil, same} is not useful Is the lexicon for unit testing really so inflexible? The case for pass_{if/unless} and fail_{if/unless} would be that it uses mental constructs that programmers are familiar w/ (in fact, it lines up perfectly w/ oneliner if/unless clauses). That's not a ridiculous suggestion if people want to change the unit testing vocab. Sure, there is an extent argument to be made, but it's not like we're trapezing off into a world where white is black and up is down. We've got sensibilities to guide us on this :P Personally i'm still not entirely sure why the methods are changing in the first place, but i definitely think that a pass/fail dichotomy is much more sensible or attractive than an assert/refute one. I'm still happy with assert_not_equal :P anyway, my 2 cents. -t 2008/10/9 Rados�aw Bu�at : > On Thu, Oct 9, 2008 at 1:33 AM, Jim Freeze wrote: >> On Wed, Oct 8, 2008 at 5:08 PM, Jean-Fran�ois Tr�n >> wrote: >>> 2008/10/8 Eric Mahurin : >>> fail_if_match = assert_no_match >>> fail_if_nil = assert_not_nil >>> fail_if_equal = assert_not_equal >>> fail_if_same = assert_not_same >> >> Those read very well. >> >>> and there can be fail_unless_* ... >> >> I would rather see pass_if_* which I assume would be an alias for assert_* >> > > fail_if_* is as bad as refute_*. It's very readable but it brings new > words to test unit world. Testing is about asserting. When I want to > test some facts I want assert it and assert_not is for opposite. > > If is fail_if_* maybe we should have dont_fail_if?... > > Before miniunit: > assert_equal 1, 1 > assert_not_match /two/, 'one 2 three' > > With miniunit: > dont_fail_if_equal 1, 1 > fail_if_match /two/, 'one 2 three' > > > -- > Rados�aw Bu�at > > http://radarek.jogger.pl - m�j blog >