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