RE: thinking about variable context for like()
Is anyone going to develop this, or is all of this just wishfull/theorhetical thinking? If someone will develop this are we going to add it to Test::More or create a module wrapped around Test::More with the added functionality? Toodles, ~~Andrew (Chrom sorry about the repeatforgot to use the "Reply-All" option) > -Original Message- > From: chromatic [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 12:24 PM > To: Potozniak, Andrew > Cc: [EMAIL PROTECTED] > Subject: 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()
Potozniak, Andrew wrote: > > Is anyone going to develop this, or is all of this just > wishfull/theorhetical thinking? If someone will develop this are we going > to add it to Test::More or create a module wrapped around Test::More with > the added functionality? What is "this" feature you're referring to exactly ? Doesn't http://search.cpan.org/~rgarcia/Test-LongString-0.03/lib/Test/LongString.pm (uploaded yesterday) do what you want ?
Using environment variables to control long running tests (again)
This was discussed on this list back in June. I'm wanting to implement it now and am wondering if Andrew's suggestion (below) has been taken up by anyone. Is PERL_TEST_LONG what people here generally expect to be the right environment variable to set to enable long-running tests? (I know I could just pick something and document it, but I'm working on Least Surprise here.) Kake On Fri 06 Jun 2003, Andrew Savige <[EMAIL PROTECTED]> wrote: > Since no experienced perl-qa'er has leapt in, and against my better > judgement, I suggest an environment variable name of: > > PERL_TEST_LONG > > Paranoid/masochistic folks and automated test harnesses can set this > variable to ensure all tests are run, even the long running ones.
Re: Using environment variables to control long running tests (again)
--- Kate L Pugh <[EMAIL PROTECTED]> wrote: > This was discussed on this list back in June. I'm wanting to > implement it now and am wondering if Andrew's suggestion (below) has > been taken up by anyone. Is PERL_TEST_LONG what people here > generally > expect to be the right environment variable to set to enable > long-running tests? I don't know if something like that's been implemented or not, but I think it's something that should be implemented by the user and probably not be pushed into the core testing suite. Also, I would recommend something like PERL_SKIP_LONG_TESTS. By default, all tests should be run to prevent the user accidentally forget to run some tests. If any tests are skipped, it should be by the explicit instruction by the person running the test lest nasty surprises crop up. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Using environment variables to control long running tests (again)
Ovid wrote: > --- Kate L Pugh wrote: > > This was discussed on this list back in June. I'm wanting to > > implement it now and am wondering if Andrew's suggestion (below) has > > been taken up by anyone. Is PERL_TEST_LONG what people here > > generally > > expect to be the right environment variable to set to enable > > long-running tests? I followed merlyn's suggestion and used PERL_SMOKE. That is, the long- running tests are skipped by default; they are run only if the user sets the PERL_SMOKE environment variable. Since the name is arbitrary, it makes little sense for each developer to invent her own different name for the same purpose, hence my initial query. > I don't know if something like that's been implemented or not, but I > think it's something that should be implemented by the user and > probably not be pushed into the core testing suite. Having an agreed name requires no changes to any test harnesses, the user controls simply by setting the PERL_SMOKE environment variable. > Also, I would recommend something like PERL_SKIP_LONG_TESTS. By > default, all tests should be run to prevent the user accidentally > forget to run some tests. If some tests take hours to run, running them by default will annoy interactive users, in particular those running the CPAN shell. /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time.
Re: Using environment variables to control long running tests (again)
On Wed, Nov 19, 2003 at 09:30:19AM +1100, Andrew Savige wrote: > > Also, I would recommend something like PERL_SKIP_LONG_TESTS. By > > default, all tests should be run to prevent the user accidentally > > forget to run some tests. > > If some tests take hours to run, running them by default will annoy > interactive users, in particular those running the CPAN shell. Disabling tests for subjective reasons (they take "too long", they don't test critical functionality, etc...) is a slippery slope. For that reason I'd agree with Curtis and say that everything is always run by default and users can then elect what to turn off. PERL_SKIP_LONG_TESTS seems like a clear name. If users find tests annoying then can turn them off, or ignore them or not run them at all. Because the user impulse is more often to weaken the tests than the strengthen them, the default should always be the strongest testing position. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ "Congratulations, you're a thieving bastard... Now give me back my pants." "That's MISTER Pants!" -- Ian's Adventures In Morrowind http://www.machall.com/morrowind/page3.html
Re: thinking about variable context for like()
On Tue, Nov 18, 2003 at 12:23:19PM -0500, Potozniak, Andrew wrote: > Is anyone going to develop this, or is all of this just > wishfull/theorhetical thinking? Boy, that sounds like a volunteer if I ever heard one! Anyhow, it looks like Test::LongString is what you want. Now say thank you to Rafael. :) > If someone will develop this are we going to add it to Test::More What's this "we" stuff, bub? :) No new functions are going into Test::More. The interface is pretty much done. This is ok because... > or create a module wrapped around Test::More with the added functionality? ...you don't write wrappers around Test::More. You use the same underlying class Test::More does: Test::Builder. This includes, oddly enough, like()! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Do not try comedy at home! Milk & Cheese are advanced experts! Attempts at comedy can be dangerously unfunny!
Re: Using environment variables to control long running tests (again)
Michael G Schwern wrote: > Disabling tests for subjective reasons (they take "too long", they don't > test critical functionality, etc...) is a slippery slope. For that reason > I'd agree with Curtis and say that everything is always run by default > and users can then elect what to turn off. PERL_SKIP_LONG_TESTS seems like > a clear name. > > If users find tests annoying then can turn them off, or ignore them or > not run them at all. Because the user impulse is more often to weaken > the tests than the strengthen them, the default should always be the > strongest testing position. I think PERL_SKIP_LONG_TESTS is a fine name. Given the sometimes heated discussion in this thread: http://www.perlmonks.org/index.pl?node_id=254011 I doubt the two camps will ever agree on this issue. My view is that it is up to the individual CPAN author how he wants to treat the naive user (i.e. the user who installs his module without explicitly setting any environment variable). That is, the CPAN author can choose whether he wants to use PERL_SMOKE or PERL_SKIP_LONG_TESTS (based on his good taste and sound judgement, after all it is his module). I think the two environment variables can happily coexist as shown in the table below: PERL_SMOKE PERL_SKIP_LONG_TESTS Naive User0 0 Contrary User 1 1 Impatient User0 1 Robot 1 0 Naive: Gets default behaviour desired by CPAN author Contrary: Gets opposite of default behaviour desired by CPAN author Impatient: Never runs long tests Robot: Always runs long tests /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time.
Re: Using environment variables to control long running tests (again)
Michael G Schwern wrote: Disabling tests for subjective reasons (they take "too long", they don't test critical functionality, etc...) is a slippery slope. I've seen this approach used successfully in a commercial setting. The key is to make sure that the long tests do get run by someone. If users find tests annoying then can turn them off, or ignore them or not run them at all. Because the user impulse is more often to weaken the tests than the strengthen them, the default should always be the strongest testing position. Note that this might put pressure on test writers to not write a more complex test, if they feel guilty about the extra exection time it would require. -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/
