Re: Test2::Tools::Compare is vs. like

[Chad Granum]

The hash/field/etc builder system is always optional. You can always mix
them, it is perfectly fine to use the builders for both 'is' and 'like',
though for the builders it really does not matter which of the 2 you use
since strict/relaxed only applies to conversions of
hashrefs/arrays/scalars,  checks you build using the builders don't get
converted (though embedded hashes and arrays will).

is(
$foo,
{ # This hash is converted to checks using the strict conversion
foo => hash { # Not converted
# 'strict' conversion to string check
field a => 'xxx';

# This hash is converted using strict (cause we are inside an
is())
field b => { foo => 'bar' };

# This being here makes the foo => hash { ... } check strict. If
# end() was not specified here it would be a relaxed check,
is/like
# do not control/alter it.
end();
}
},
"description"
);

Here is a sub example for you:

like(
{foo => 'foo' },
{foo => sub { $_ eq 'foo' ? 1 : 0 } },
"Useless and trivial example of using a sub check in like"
);



On Wed, Jul 27, 2016 at 8:34 AM, Andy Lester  wrote:

>
> On Jul 27, 2016, at 10:13 AM, Chad Granum  wrote:
>
> Specifically "This will ignore hash keys or array indexes that you do not
> actually specify in your $expect structure." directly documents the
> behavior.
>
>
> Right.  That is a fact that is clearly spelled out.  I think it would be
> helpful to have something that is higher level, that explains when you use
> which, and examples for each.
>
> For instance, it might be something like (if my understanding is correct).
>
> my $employee = get_employee();
> my $expected_employee = { name => ‘Bob’, dept => ‘IT’ };
>
> # If you want to check the API, and ensure that get_employee() returns
> two and only two fields:
> is( get_employee(), $expected_employee );
>
> # If you want to check that you got the right record, but don’t care
> if it comes back with, say, a phone_number field:
> like( get_employee(), $expected_employee );
>
> Also, when do you have to use the hash/field construction system?
>
> is( $employee, { name => 'Bob', dept => 'IT' } );
> like( $employee, { name => 'Bob', dept => 'IT' } );
> is( $employee, hash {
> field name => 'Bob';
> field dept => 'IT';
> }
> );
>
> When is it appropriate to use each of these?  Is it an error to mix like()
> and hash()/field()?
>
> An example of calling like() on coderefs ("The same is true for coderefs,
> the value is passed in as the first argument (and in $_) and the sub
> should return a boolean value.”) would be good, too.
>
> I’d be glad to write the docs if I knew the answers to the questions and
> the zen of what to use when.
>
> As a newbie to Test2, I’d really like to start using it as much as
> possible, but I’m also afraid of screwing up existing tests because I use a
> new tool incorrectly.
>
> Andy
>
>
> --
> Andy Lester => www.petdance.com
>
>

Re: Test2::Tools::Compare is vs. like

[Andy Lester]

> On Jul 27, 2016, at 10:13 AM, Chad Granum  wrote:
> 
> Specifically "This will ignore hash keys or array indexes that you do not 
> actually specify in your $expect structure." directly documents the behavior.
> 


Right.  That is a fact that is clearly spelled out.  I think it would be 
helpful to have something that is higher level, that explains when you use 
which, and examples for each.

For instance, it might be something like (if my understanding is correct).

my $employee = get_employee();
my $expected_employee = { name => ‘Bob’, dept => ‘IT’ };

# If you want to check the API, and ensure that get_employee() returns two 
and only two fields:
is( get_employee(), $expected_employee );

# If you want to check that you got the right record, but don’t care if it 
comes back with, say, a phone_number field:
like( get_employee(), $expected_employee );

Also, when do you have to use the hash/field construction system?

is( $employee, { name => 'Bob', dept => 'IT' } );
like( $employee, { name => 'Bob', dept => 'IT' } );
is( $employee, hash {
field name => 'Bob';
field dept => 'IT';
}   
);

When is it appropriate to use each of these?  Is it an error to mix like() and 
hash()/field()?

An example of calling like() on coderefs ("The same is true for coderefs, the 
value is passed in as the first argument (and in $_) and the sub should return 
a boolean value.”) would be good, too.

I’d be glad to write the docs if I knew the answers to the questions and the 
zen of what to use when.

As a newbie to Test2, I’d really like to start using it as much as possible, 
but I’m also afraid of screwing up existing tests because I use a new tool 
incorrectly.

Andy


--
Andy Lester => www.petdance.com

Re: Test2::Tools::Compare is vs. like

[Chad Granum]

I thought I had documented the differences pretty well. If you look here
https://metacpan.org/pod/Test2::Tools::Compare#COMPARISON-TOOLS and read
both the 'is()' and 'like()' sections it makes it clear.

is:

> his is the strict checker. The strict checker requires a perfect match
> between $got and $expect. All hash fields must be specified, all array
> items must be present, etc. All non-scalar/hash/array/regex references must
> be identical (same memory address). Scalar, hash and array references will
> be traversed and compared. Regex references will be compared to see if they
> have the same pattern.
>

like:

> This is the relaxed checker. This will ignore hash keys or array indexes
> that you do not actually specify in your $expect structure. In addition
> regex and sub references will be used as validators. If you provide a regex
> using qr/.../, the regex itself will be used to validate the corresponding
> value in the $got structure. The same is true for coderefs, the value is
> passed in as the first argument (and in $_) and the sub should return a
> boolean value. In this tool regexes will stringify the thing they are
> checking.
>

Specifically "This will ignore hash keys or array indexes that you do not
actually specify in your $expect structure." directly documents the
behavior.


That said I have no opposition to making the docs more clear, and am open
to suggestions on how to reword or reorganize it.

-Chad

On Wed, Jul 27, 2016 at 8:03 AM, Andy Lester  wrote:

> I was going to mail this to Chad directly, but I think it’s worth airing
> publicly.
>
> As a newcomer to Test2, it was never clear to me until just now when to
> use is() or like() for deep structures.  Given this code:
>
> my $errors = do_something();
> is( @{$errors}, 0. ‘No errors back from do_something()’ ); # old way
>
> And the new way to check would be:
>
> is( $errors, [], ‘No errors back from do_something()’ );
>
> It would be very easy to use this instead:
>
> like( $errors, [], ‘No errors back from do_something()’ );
>
> And it looks like like() works just fine, but really it will pass even if
> $errors has something in it.
>
> is( [], [] ); # Passes
> like( [‘foo’], [] ); # passes but you wouldn’t expect it to.
>
> The docs say "This is the strict checker” and “This is the relaxed
> checker” for each of them, respectively, but I think it would be worth
> having something in the docs that explains the differences between the two.
>
> Anyone else have troubles with these two functions?  Or other gotchas
> where new features aren’t what people switching from Test::More might
> expect?
>
> Andy
>
> --
> Andy Lester => www.petdance.com
>
>

Test2::Tools::Compare is vs. like

[Andy Lester]

I was going to mail this to Chad directly, but I think it’s worth airing 
publicly.

As a newcomer to Test2, it was never clear to me until just now when to use 
is() or like() for deep structures.  Given this code:

my $errors = do_something();
is( @{$errors}, 0. ‘No errors back from do_something()’ ); # old way

And the new way to check would be:

is( $errors, [], ‘No errors back from do_something()’ );

It would be very easy to use this instead:

like( $errors, [], ‘No errors back from do_something()’ );

And it looks like like() works just fine, but really it will pass even if 
$errors has something in it.

is( [], [] ); # Passes
like( [‘foo’], [] ); # passes but you wouldn’t expect it to.

The docs say "This is the strict checker” and “This is the relaxed checker” for 
each of them, respectively, but I think it would be worth having something in 
the docs that explains the differences between the two.

Anyone else have troubles with these two functions?  Or other gotchas where new 
features aren’t what people switching from Test::More might expect?

Andy

--
Andy Lester => www.petdance.com