Yitzchak Scott-Thoennes wrote:
> On Thu, February 12, 2009 4:20 am, Gabor Szabo wrote:
>> the one in the docs looks like this:
>>
>> # $foo isn't empty
>> isnt( $foo, '', "Got some foo" );
>>
>> which feels such a weak test I don't think I'd write it.
>
> Somewhat longer version of the same thing:
>
> my $warn = '';
> %SIG{__WARN__} = sub { $warn .= "@_" };
> ...
> isnt( $warn, '', 'Unexpected warnings during test run' );
Shouldn't that be using is()?
Before I go justifying it, really isnt() is there because then there can be
isn't(). :) All interface concerns are trumped by cheap programming jokes.
Going back historically, isnt() predates cmp_ok(). Prior to cmp_ok() there
was no way to express "this is not that" and find out what *this* was. isnt()
filled that gap.
isnt() and unlike() are there because sometimes you don't know what a thing
should be, but what it shouldn't be. isnt() is rather narrow, in fact the
example is probably dangerous because of how is() (and thus isnt) treats undef.
$foo = undef;
isnt( $foo, '' ); # this passes, because '' isn't undef to is()
In a lot of cases, cmp_ok() might be better.
cmp_ok( $foo, 'ne', "" );
I think Erik's use case is strongest. But it should be paired with a test to
verify that $next_seq and $seq are following the correct format.
new_ok $obj, "Foo";
my $clone = $obj->clone;
isa_ok $obj, "Foo", "Foo->clone";
isnt $obj, $clone, "clone() produces a different object";
Here's an example in the wild.
http://cpansearch.perl.org/src/ZEFRAM/Data-ID-Maildir-0.002/t/id.t
Sometimes really all you can say is there's a hunk of something there, like if
your sequence was nothing more than a unique stream of bits. Or this:
isnt $exit, 0, "expected abnormal exit";
A pedant might also check that $exit is, in fact, a number. And again, the
undef isnt 0 gotcha strikes.
So, who's going to try out the fabulous new github fork-and-patch mechanism
and rewrite the isnt() docs?
--
Defender of Lexical Encapsulation
