Re: Writing our own modules in Test2
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
On Mon, Jun 27, 2016 at 4:34 PM, Andy Lesterwrote: > > 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
> On Jun 24, 2016, at 4:41 PM, Buddy Burdenwrote: > >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
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
> On Jun 24, 2016, at 12:57 PM, Buddy Burdenwrote: > > 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
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
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
> On Jun 24, 2016, at 12:46 AM, Chad Granumwrote: > > 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
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