Descriptive strings in Test::More ?
(ergh, let's try this again from the right address) I'm not sure where's the best place to post this, but I imagine perl-qa might be a good start. Please let me know if it's the wrong place. I've been messing with various testing modules that I learnt about at YAPC, and I'm unclear about something. use Test::More no_plan; ok( nonblank("abc") eq "OK" , "Strings aren't blank" ); The above is generated using Pod::Tests and pod2test (yay schwern!). When I run these tests, I never see the descriptions of the tests (eg "Strings aren't blank"). I thought those strings were meant to output during the testing, to show you what it's testing for. Am I confused? K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
Descriptive strings?
I'm not sure where's the best place to post this, but I imagine perl-qa might be a good start. Please let me know if it's the wrong place. I've been messing with various testing modules that I learnt about at YAPC, and I'm unclear about something. use Test::More no_plan; ok( nonblank("abc") eq "OK" , "Strings aren't blank" ); The above is generated using Pod::Tests and pod2test (yay schwern!). When I run these tests, I never see the descriptions of the tests (eg "Strings aren't blank"). I thought those strings were meant to output during the testing, to show you what it's testing for. Am I confused? K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "My secret weapon is PMS." -- Buffy the Vampire Slayer
Re: Docs on testing?
In lists.projects.perl.perl-qa, you wrote: >I am not a newcomer to this list, just a squatter and I have been >programming Perl for about a year now (and lovin' every minute of it). After >reading all the postings on this list about Test::Simple, etc... I was >wondering, are there any (or plans to create any) docs that explain how to >write tests? I believe I volunteered to do that the other day. More fool me :) K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ There's nothing wrong with me; therefore, there must be something wrong with the universe.
Re: Descriptive strings?
On Tue, Jun 19, 2001 at 08:42:29PM -0400, Michael G Schwern wrote: | | I assume you're talking about "make test"? Test::Harness in | non-verbose mode (ie. "make test") won't display any of that info. If | you set $verbose = 1 you'll see all the test output. For failed tests | it will just report their numbers. Where do I set $verbose? | Currently, Test::Harness is not aware of test names at all. It just | ignores the extra info. I'm not sure what I'm going to do about that. | As sort of a simple, half-ass solution I'm going to have Test::Harness | dump its verbose output to a file (test.out?) by default. Hrm. What I want is to achieve this: # This produces "ok 1 - Hell not yet frozen over" (or not ok) ok( get_temperature($hell) > 0, 'Hell not yet frozen over' ); (from the Test::Simple perldoc) when I run "make test". K.
Re: QA-esque summary of TPC
Schwern wrote: > >Dangermouse > >We watched Dangermouse, The Avenging Disco Godfather and probably too >much Monty Python for our own good. Put yo' WEIGHT on it! I can see how Danger Mouse might be considered quality, but Avenging Disco Godfather? No way. >Adam Turoff gave a talk about stealing ideas from LaTeX, XML and SGML >and incorporating them into POD. I missed it. Anyone go? No, but it's in the proceedings, and I'm kind of familiar with the topic, so I'll attempt a brief rundown in my own words: 1. These days it's fashionable for markup languages to describe the content, not the presentation. This helps computers parse them better. For instance, Je ne sais quois is less recognisable as a phrase in a foreign language than Je ne sais quoi 2. POD, as it currently stands, is almost entirely presentation-based. For instance, =head1 produces a level one heading but doesn't actually say much about the structure of the document; B<> says something's bold but doesn't say why. 3. Adam's proposal is that semantic tags would be useful in POD, primarily for converting between POD and other semantic markup languages such as Docbook. He has invented some new POD-like tags for this: =chapter =section =appendix =title =fpara (a formal paragraph, i.e. a para with a title) =list =code em<> function<> literal<> 4. This would then make it easy to convert to/from Docbook, another very common/popular documentation markup language. This means that you don't have to know all of Docbook to write Docbook -- you can write in this cut-down, intermediate level: DocPOD 5. There are some modules for doing the translation etc, see DocPod::*, presumably on CPAN. HTH, K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Be pedantic in what you accept, and arbitrarily brutal in what you send." -- Malcolm Ray in a.s.r
Re: Pod::Coverage random silliness
In perl.qa, you wrote: >On Tue, Aug 28, 2001 at 07:56:30PM -0400, Kirrily 'Skud' Robert wrote: >> This script... > >Nifty, mind if I assimilate it as an example script? Not at all. Credit as Kirrily "Skud" Robert <[EMAIL PROTECTED]> please. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ How do I set my LaserPrinter to "Stun"?!
ANNOUNCE: Test::Mail 0.03
Now winging its way towards CPAN mirrors worldwide. I've implemented it pretty much as described the other day. Comments etc welcome. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Sure, only 2 percent of the Internet population uses lynx, but they're the top 2 percent." -- petro, on a.s.r
Re: Wiki Wiki not Wiki Working
In perl.qa, you wrote: >Will do. No! Read on! It's been done already. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Any sufficiently fucked-up technology is indistinguishable from magic.
Re: [PATCH] More Test::More stuff
In perl.qa, you wrote: >> >> eval { ...code... }; >> is( $@, '' ); > >Yeah, except that doesn't print out $@ in case of failure. If I'm >checking that no exception occurs I want to know what the exception is >when it happens. But it does! It says something like: not ok 23 # Failed test 1 (eval.t at line 69) # got: 'blah blah blah' # expected: '' K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "There are three degrees of being weird. There are: 1) Salvageably weird. 2) Weird. 3) Irrevocably weird." -- Carrie Fisher
Re: What tests are failing on VMS?
In perl.qa, you wrote: >So like I said, either tests are habitually failing on vmsperl, or >nobody's compiled Perl on OS/390 in a long time (I wouldn't be >surprised if that were true). I assume you mean "MVS"? K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ We have only two things to worry about: either that things will never get back to normal, or that they already have.
Re: Wiki Wiki Working
In perl.qa, you wrote: > >If someone would be so kind as to fill in TestTutorial from the latest >version of Test::Tutorial? Done. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Verbogeny is one of the pleasurettes of a creatific thinkerizer." -- Peter da Silva
Re: FAIL Module-InstalledVersion-0.02 cygwin-multi 1.3.2(0.3932)
In perl.qa, you wrote: >On Thu, 13 Sep 2001 19:41:39 -0400 >Kirrily 'Skud' Robert <[EMAIL PROTECTED]> wrote: > >> Anyone know what might cause this? The same reporter also had the same >> problem with CPAN-Test-Reporter. > >His Test::Harness needs upgrade? Yeah, I guess that'd be it. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Any sufficiently advanced political correctness is indistinguishable from irony. - Erik Naggum
Re: Test::Harness::Straps
In perl.qa, you wrote: >On Thu, Sep 20, 2001 at 10:35:49AM -0400, Shane Landrum wrote: >> So, I've just found Test::Harness::Straps--- thanks to Skud >> for pointing me in the right direction. Anyone else using it? >> I'm working on using it to write a web-based test summarizer >> for my users. >> >> Schwern, do you have plans for releasing T::H 2.00 to CPAN >> as anything other than an alpha? What do you need to see >> before you release it? > >Hmmm, more people trying it, really, especially on the weird >platforms. I rewrote all the test analysis logic and I still afraid I >broke something. We're probably going to start using it for e-smith's testing foo. I've dinked around with it briefly, enough to know that it does roughly what I want, but I'm not on any kind of unusual platform or anything, so I don't know if that's at all helpful. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Make a fist, Benno. No, that's too big." -- Renee (from the Netizen quotes file)
Re: Test::Harness in Test-SDK conflicts with Perl
In perl.qa, you wrote: >On Tue, Oct 09, 2001 at 10:10:33PM +0200, Johan Vromans wrote: >> Michael G Schwern <[EMAIL PROTECTED]> writes: >> > Debian has the beginnings of that. perl-base is the minimum necessary >> > to have a useful Perl, basically a binary, the perl man page, and a >> > handful of critical modules ... >> >> Wouldn't it be a good idea to try to define packages like these, so >> that packagers can all make consistent packages? > >Come again? I think he's trying to say that Perl (i.e. the "Perl community") should define these things so that different packagers (Debian, Red Hat, whoever) can have somewhat-consistent packages. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ If it's not broken, break it.
Re: Test::Builder: Multiple test libraries in one test.
In perl.qa, you wrote: >Candidates for this sort of thing would be CGI::Test, Test::Cmd, >Test::Unit, Test::Mail and ExtUtils::TBone. And, of course, Barrie's >Test::Differences. Actually, Test::Mail doesn't work like that. It's more or less a wrapper around Test::More that handles incoming email. Doesn't implement any of its own ok()-like routines at all, just makes it easy to use Test::More's routines on incoming email. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Usenet: open mouth, insert foot, propagate internationally
Re: is() with arbitrary comparisions
In perl.qa, you wrote: >I think I have a solution to the rigidity of is(). ie. something with >the diagnostic output of is(), but the flexibility of ok(). >It all makes sense, so what I really need is a better name. How about: compare($foo, "<=", $bar) K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ "Does anyone know my root password?" --Renee (from the Netizen quotes file)
SKIP blocks and the debugger
Does anyone else find that SKIP: { } blocks bugger up the debugger? I'll be happily bouncing on the "n" key to get to round about the vicinity of the failing test, and then blam, it sees a skipped test and just fast-forwards to the end. K. -- Kirrily Robert [EMAIL PROTECTED] http://infotrope.net
Re: Trends in Code Quality
I'm with Aristotle. I think it's an urge that's come out of the development community -- specifically, *certain* development communities -- rather than from an end-user desire for quality. Many of the best -tested pieces of software are the infrastructure type things that only developers ever really know about, and functional testing ("does this software do what I want it to?") is far less common than unit testing at the API level. In my experience developers latch on to test-driven development like a crack habit because once they get into the swing of it, it really is a very effective, stress-reducing way to work. K.
Info from Devel::Cover
I've got a guy at work who wants to take coverage reports and bung them in a database so he can track historical coverage data. As I see it, he needs to somehow parse the stuff in cover_db/ but neither he nor I understand what's in there. Do any modules already exist for this? I believe the thing that generates the coverage reports currently is C code or something? So isn't there anything CPANish to do this? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://infotrope.net/
RE: Anyone experiencing problems with rt.cpan.org?
There were some people talking about problems with it the other day (Thursday?) on magnet #perl. I think Adam Kennedy mentioned slowness, and Jesse was around at the time and sounded like he was going to look into it. Yeah, I know, vague. K.
Fixtures
Does anyone here understand "fixtures" as a testing concept, and could they please explain it to me in a Perlish way? At least half of what I've heard described is what I usually achieve with a t/data/ directory, and another half is what I'd do by writing a specialized Test::Builder-based module. K.
RE: Fixtures
Thanks all, especially Ovid who came closest to answering the actual question, i.e. can someone explain it to me *in a perlish way*. Ovid's example used Test::Class's setup/teardown; would anyone else be able to provide confirm that I'm making sense in the following Test::Harness/Test::More style example: 1. Assume a test file t/foo.t 2. Assume a directory t/data (or t/fixtures if you will -- I just call it data in my own tests). 3. Create a file t/data/foo.yml (or whatever data format) containing the data needed by the tests in foo.t 4. At the beginning of foo.t, load data/foo.yml into whatever data structure (memory, SQLite, real database, etc) 5. Run tests against foo.t 6. When foo.t exits, tear down the data created in step 4. Yes? In other words "fixtures" is just a jargony name for t/data/, right? And, is the above setup/teardown stuff right, or would you do it before each individual test? That would seem to be nearly nonsensical, but then, I've seen stupider ideas. My earlier comment about Test::Builder-based test modules was that some of the fixtures stuff I've seen used repeated code chunks to go over the contents of foo.yml, for instance doing validation runs against each record, and it looked to me as if the Perlish way to do that is to write a test module that provides record_is_valid() and related stuff. As I understand it now, this isn't actually part of "fixtures" conceptually, it's just something that one might tend to see near fixtures. K.
Tests fail under load
We've got a situation where we have a suite of tests for a web app. It starts of testing the lib/ and whatnot, but eventually gets to the point where it uses Test::WWW::Mechanize to go fetch stuff from the developer's sandbox website and do a sanity check on the web application itself. The problem is that all the developer sandbox websites run on one server that's groaning under the strain. It's in the process of being replaced but we're not there yet. The upshot of this is that on a good day, the web tests take ages to run, and on a bad day they time out. It's got to the point where the developers just kind of mentally tune out failures in the web tests, and I'm worried about the "broken window" effect. Any suggestions for how to work around this? All I've got so far is the idea of splitting out the web tests into another directory, and treating them as "functional tests" that developers would typically run less often than the unit tests. K.
What was I thinking?
In September 2001, apparently all aglow in the excitement of all the talk that was going on about testing and whatnot, I wrote a module called CPAN::Test::Reporter. (http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at it, I have no idea what I was thinking or why I thought it was necessary at the time. The only hint is in the credits where I say that it's based on the cpantest script by Kurt Starsinic. Presumably I thought it would be useful to have a modular version of it. I'm pretty sure nobody uses it (CPANTS reports that it's not a dependency for any other module). It looks like Test::Reporter is a newer module that does what I was trying to do, and is more up to date. What I want to know is, should I just bin it? Or might it, in fact, be useful to someone somehow? Or is it just bad form to completely delete CPAN modules? I guess I could update it with a new version that says "Don't use me." K. -- Kirrily Robert [EMAIL PROTECTED] [EMAIL PROTECTED] http://infotrope.nethttp://search.cpan.org/author/SKUD
what was I thinking?
In September 2001, apparently all aglow in the excitement of all the talk that was going on about testing and whatnot, I wrote a module called CPAN::Test::Reporter. (http://search.cpan.org/~skud/CPAN-Test-Reporter-0.02/) Looking at it, I have no idea what I was thinking or why I thought it was necessary at the time. The only hint is in the credits where I say that it's based on the cpantest script by Kurt Starsinic. Presumably I thought it would be useful to have a modular version of it. I'm pretty sure nobody uses it (CPANTS reports that it's not a dependency for any other module). It looks like Test::Reporter is a newer module that does what I was trying to do, and is more up to date. What I want to know is, should I just bin it? Or might it, in fact, be useful to someone somehow? Or is it just bad form to completely delete CPAN modules? I guess I could update it with a new version that says "Don't use me." K. -- Kirrily Robert [EMAIL PROTECTED] [EMAIL PROTECTED] http://infotrope.nethttp://search.cpan.org/author/SKUD