Re: thinking about variable context for like()
Potozniak, Andrew wrote: > > I would suggest something along the lines of: > > &like_html(actual_value, expected_regex, max_chars_to_output, > string_description); In fact I think that making max_chars_to_output a global configuration variable is a better option, because repeating it (if you have lots of tests) will become quickly fastidious.
Re: Refactoring a test program: advice sought
* Andrew Savige [2003-11-15 14:51]: > I took a quick look a mod_perl and Template Toolkit (TT). > TT has a: > lib/Template/Test.pm > which looks wrong to me (should that not be under t/lib instead?). Template::Test contains a bunch of (pre-Test::More) testing methods that are geared towards writing TT tests. Some of my TT plugins use Template::Test instead of Test::More. (darren) -- There's no money in poetry, but there's no poetry in money, either. -- Robert Graves pgp0.pgp Description: PGP signature
RE: thinking about variable context for like()
Maybe I'm off with my next comment and maybe I'm not but here it goes: What you're suggesting is a difference between mechanizm and policy. We want a function that will be just like Test::More::like, but we want it to only output a certain amount of chars because frankly we don't want to see all of the HTML. The function like_html(actual_value, expected_regex, max_chars_to_output, string_description) is our mechanizm. The global config var is a policy. What's stopping you from creating this global var and passing it in to the function whenever it is called? Or you could make the function "smart" enough as to if there isn't a max_chars_to_output param it looks for a certain "global config var" and if that's undefined it acts just like Test::More::like. The implementation is your choice, but one thing you should consider is the separation between your function's mechanizm and policy. Toodles, ~~Andrew > -Original Message- > From: Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 4:24 AM > To: Potozniak, Andrew > Cc: [EMAIL PROTECTED] > Subject: Re: thinking about variable context for like() > > > Potozniak, Andrew wrote: > > > > I would suggest something along the lines of: > > > > &like_html(actual_value, expected_regex, max_chars_to_output, > > string_description); > > In fact I think that making max_chars_to_output a global > configuration variable is a better option, because repeating > it (if you have lots of tests) will become quickly fastidious. >
RE: thinking about variable context for like()
On Mon, 2003-11-17 at 06:54, Potozniak, Andrew wrote: > What's stopping you from creating this global var > and passing it in to the function whenever it is called? Good taste. If it's going to be more convenient than Test::More's like(), go all the way and make it more convenient. > Or you could make the function "smart" enough as to if there > isn't a max_chars_to_output param it looks for a certain "global > config var" and if that's undefined it acts just like Test::More::like. Sure, either of those are fine. I can't imagine saying "I want a hundred characters in this test but a hundred and three in the next test" very often. I can imagine saying "I want a hundred characters in every test, except for this test over here -- but I'll mark that as a special exception right where it needs to be marked". Oh, and putting the length variable before the test name feels wrong, too. Here's a wacky idea: in void context, like() behaves as normal (barring any default limits). In scalar context: like( $var, $regex, $name ) or diag( "No regex match!" ); set two variables of the appropriate length? I'm not sure I like it better, but it's an idea. -- c
Re: thinking about variable context for like()
Chromatic wrote in perl.qa : > On Mon, 2003-11-17 at 06:54, Potozniak, Andrew wrote: > >> What's stopping you from creating this global var >> and passing it in to the function whenever it is called? > > Good taste. If it's going to be more convenient than Test::More's > like(), go all the way and make it more convenient. Thanks, but actually that's due to my habit of adding tests to files that already contain hundreds of tests written by a dozen of people. Adding a test should be made the most straightforward possible and an interface shouldn't puzzle people. Moreover, it's convenient, when you debug a module, to have a more useful drop-in replacement for whatever test subroutine you have. That's how Test::LongString::is_string works : you can get a test file, include "use Test::LongString" at the top, and replace the offending is() by is_string() to have more readable diagnostics. You can always tweak the defaults later, but it's more convenient to do this by bringing the least possible modification to the test code itself. (That's why I can imagine accepting the default length as an argument to Test::LongString::import().)
Re: Refactoring a test program: advice sought
On Mon, 17 Nov 2003, darren chamberlain wrote: > * Andrew Savige [2003-11-15 14:51]: > > I took a quick look a mod_perl and Template Toolkit (TT). > > TT has a: > > lib/Template/Test.pm > > which looks wrong to me (should that not be under t/lib instead?). > > Template::Test contains a bunch of (pre-Test::More) testing methods that > are geared towards writing TT tests. Some of my TT plugins use > Template::Test instead of Test::More. And Mason includes a module caled HTML::Mason::Tests in its distro. I've used that module for my MasonX::Request::WithApacheSession module, and I expect it to be installed as part of the Mason core code. This seems useful for things like templating tools and other things which create their own environment, like mod_perl, POE, etc. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: thinking about variable context for like()
FWIW, I uploaded Test::LongString 0.03 to CPAN. It implements like_string() and unlike_string(), and also : > (That's why I can imagine accepting the default length as an argument > to Test::LongString::import().)
