Re: Writing our own modules in Test2

2016-07-02 Thread Buddy Burden

Andy,


I don’t like the name bool_eq() (“booleans are equal”) but it was the
best I could come up with.


I still like `is_true` and `is_false`. :-)


-- Buddy


Re: Writing our own modules in Test2

2016-06-30 Thread Lasse Makholm
On Mon, Jun 27, 2016 at 4:34 PM, Andy Lester  wrote:

>
> On Jun 24, 2016, at 4:41 PM, Buddy Burden  wrote:
>
>is_true($val);
>is_false($val);
>
> Because with just `ok($val)` you can tell whether it's true or false, but,
> when it inevitably fails, you really want to know what the bad value turned
> out to be.
>
>
> I have a bool_eq() so you can do this:
>
> bool_eq( $want_foos, scalar @foos );
>
> without having to do
>
> if ( $want_foos ) {
> ok( scalar @foos );
> }
> else {
> is( scalar @foos, 0 );
> }
>
> We were also writing that as
>
> is( !!$want_foos, !!(scalar @foos) );
>
> which works, but obscures the meaning.
>
> I don’t like the name bool_eq() (“booleans are equal”) but it was the best
> I could come up with.
>

bool_not_xor_ok() ? :-D

Kidding aside, I would argue that using a conditional is actually the more
readable option in this particular case, though I'd probably compress it
down to:

$want_foos
? ok(scalar @foos, 'got some foos')
:  is(scalar @foos, 0, 'got no foos');

I find that minimizing the logic inside the argument list makes my tests
more readable...

That doesn't negate the need for a bool_eq() though...

How about is_truth($got_bool, $expected_bool) ?

That seems to line up nicely with is_true() and is_false()...

/L


>
> --
> Andy Lester => www.petdance.com
>
>


Re: Writing our own modules in Test2

2016-06-27 Thread Andy Lester

> On Jun 24, 2016, at 4:41 PM, Buddy Burden  wrote:
> 
>is_true($val);
>is_false($val);
> 
> Because with just `ok($val)` you can tell whether it's true or false, but, 
> when it inevitably fails, you really want to know what the bad value turned 
> out to be.


I have a bool_eq() so you can do this:

bool_eq( $want_foos, scalar @foos );

without having to do

if ( $want_foos ) {
ok( scalar @foos );
}
else {
is( scalar @foos, 0 );
}

We were also writing that as

is( !!$want_foos, !!(scalar @foos) );

which works, but obscures the meaning.

I don’t like the name bool_eq() (“booleans are equal”) but it was the best I 
could come up with.

--
Andy Lester => www.petdance.com



Re: Writing our own modules in Test2

2016-06-24 Thread Buddy Burden

Andy,


I’ve accumulated a number of test functions in our work codebase for
doing what I call “expressive” tests to avoid common cut & paste.  I’m
using the term “expressive” for now because they’re expressing what it
is you want, rather than making you write the code that explains them.


Sounds good.  I would definitely use such a module.


is_empty_array( $foo );
is_nonempty_array( $foo );

because I believe that it’s easier to read the English “is empty array”
than to translate “is( scalar @{$foo}, 0 )” into that meaning.


*Plus* it gives you an opportunity to display better diagnostics.  E.g. 
"okay, test failed, so the array's not _empty_ ... but what the hell is 
in it?"  This is exactly why I wrote:


is_true($val);
is_false($val);

Because with just `ok($val)` you can tell whether it's true or false, 
but, when it inevitably fails, you really want to know what the bad 
value turned out to be.


Anywho, things like this are, as you say, simple to write, but valuable 
in several different ways.



-- Buddy


Re: Writing our own modules in Test2

2016-06-24 Thread Andy Lester

> On Jun 24, 2016, at 12:57 PM, Buddy Burden  wrote:
> 
> What sort of methods did you have in mind?  I might have something to 
> contribute, if you would be interested in contributions.


I’ve accumulated a number of test functions in our work codebase for doing what 
I call “expressive” tests to avoid common cut & paste.  I’m using the term 
“expressive” for now because they’re expressing what it is you want, rather 
than making you write the code that explains them.


For instance, instead of doing all the 

is( scalar @{$foo}, 0 );  # Is this an empty array?
ok( scalar @{$foo} );   # Is there something in the array?

I’ve been writing

is_empty_array( $foo );
is_nonempty_array( $foo );

because I believe that it’s easier to read the English “is empty array” than to 
translate “is( scalar @{$foo}, 0 )” into that meaning.  We’ve got some 1200+ .t 
files of 11MB so I do a lot of reading of .t files all day.

Similarly:

is_nonblank( $response );
is_blank( $response );

instead of

ok( defined($response) ) && like( $response, qr/./ );
is( $response, ‘’ );

for the same reasons.  They’re common idioms, but I’d still rather read English 
than Perl.

Also, I see it that the fewer arguments passed around, the fewer places for 
mistakes.

I’ve also stolen some stuff from Test::Numeric for common tests.  is_integer, 
is_positive_integer, is_nonnegative_integer, is_even.

I’ve also got things like all_keys_exist_in( \%hash, [qw( foo bar bat )] ).

…

Now, with Test2, my thinking on many of these changes.  The odious

is( scalar @{$foo}, 0 );

now becomes simply

is( $foo, [] );

which may not be as Englishy as 

is_empty_array( $foo )

but that I am probably fine with.  So, too, does something like 
all_keys_exist_in() become much easier to do with the new DSL in Test2.  But 
there will still be others like it, I suspect.

…

I also want to have something that is an example of the Right Way To Do It that 
we can point at as an add-on distribution to Test2::Suite.  I think that will 
help future Test2::Tools writers.

So those are my high-level thoughts.

--
Andy Lester => www.petdance.com



Re: Writing our own modules in Test2

2016-06-24 Thread Buddy Burden

Andy,


My ultimate goal here is to create a batch of convenience test methods ...


What sort of methods did you have in mind?  I might have something to 
contribute, if you would be interested in contributions.



-- Buddy


Re: Writing our own modules in Test2

2016-06-24 Thread Chad Granum
The pod for Test2.pm explains the namespaces. They are intended for all new
tools/plugins/events/etc. Test2::Xxx should be for extentions to the
framework. Test2::Tools::* and test2::Plugins etc are open to anyone.
On Jun 24, 2016 7:39 AM, "Andy Lester"  wrote:

>
> On Jun 24, 2016, at 12:46 AM, Chad Granum  wrote:
>
> Is the intent that when people will create them as
> Test2::Tools::Whatever?  Sort of like Perl::Critic::Policy::* is done?  Or
> are we still staying as Test::Whatever?
>
>
> What about naming?  Test2::Tools::Whatever?  Or do we see the Test2::Tools
> namespace being only for “official” tools?
>
> I see three options for third parties:
>
> * Test2::Tools::Whatever
> * Test2::Whatever
> * Test::Whatever
>
> My ultimate goal here is to create a batch of convenience test methods and
> also have them stand as an example of a standalone third party module.
>
>
> --
> Andy Lester => www.petdance.com
>
>


Re: Writing our own modules in Test2

2016-06-24 Thread Andy Lester

> On Jun 24, 2016, at 12:46 AM, Chad Granum  wrote:
> 
> Is the intent that when people will create them as Test2::Tools::Whatever?  
> Sort of like Perl::Critic::Policy::* is done?  Or are we still staying as 
> Test::Whatever?


What about naming?  Test2::Tools::Whatever?  Or do we see the Test2::Tools 
namespace being only for “official” tools?

I see three options for third parties:

* Test2::Tools::Whatever
* Test2::Whatever
* Test::Whatever

My ultimate goal here is to create a batch of convenience test methods and also 
have them stand as an example of a standalone third party module.


--
Andy Lester => www.petdance.com



Re: Writing our own modules in Test2

2016-06-23 Thread Chad Granum
Right now the Test2::API docs are probably all that is done. But my Test2
manual grant covers the document you request as one of the 2 primary goals.
I have plans for it, and will be getting to it just as soon as I settle
back in from YAPC.
On Jun 23, 2016 7:52 PM, "Andy Lester"  wrote:

Is there a doc somewhere that explains how to write one's own test module
atop Test2?  I haven't found it if there is.

Is the intent that when people will create them as Test2::Tools::Whatever?
Sort of like Perl::Critic::Policy::* is done?  Or are we still staying as
Test::Whatever?

Do we have an FAQ started for things like this?  If not, I assume it would
be good to start one, and if so, then where should I start it?

--
Andy Lester => www.petdance.com