On Friday 07 April 2006 06:43, A. Pagaltzis wrote:
> I still wonder what’s bad about using
>
> UNIVERSAL::can( $foo, "can" )
>
> as a pre-Scalar::Util-compatible replacement of
>
> blessed( $foo )
>
> that is, purely as a boolean test where only the truthness of the
> return value is of in
On Friday 07 April 2006 05:32, demerphq wrote:
> Actually afaik there is no good way to find out what dereferencing
> operators an object supports. The best that I know of is reftype(),
> but that only tells you the objects underlying intrinsic type, it
> doesnt tell you if you can dereference the
On Friday 07 April 2006 10:48, demerphq wrote:
> On 4/7/06, chromatic <[EMAIL PROTECTED]> wrote:
> > eval { dereference_somehow( $thingie ) }
> Sure, thats what i was saying elsewhere too. But I dont consider that
> a reasonable solution. Consider if dreferencing it means e
On Sunday 16 April 2006 20:08, Andy Lester wrote:
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
How non-Perl do you want? Does the Perl 6 version o
On Monday 17 April 2006 18:09, Ovid wrote:
> Tracking the results in an object is a better choice than scraping from
> a print buffer. One of the frustrating issues with Perl's testing
> tools is the limited flexibility we have due to reading the output from
> STDOUT.
... an object of which TAP-
On Monday 17 April 2006 18:50, Ovid wrote:
> The only problem I see with that is the occasional buffering errors I
> see on my Mac where the STDERR and STDOUT don't line up.
Agreed. Is it too late to send everything to STDOUT where it belongs?
-- c
On Tuesday 18 April 2006 00:20, Ovid wrote:
> As a language-independent tool, an API is silly and
> I'm a fool for shooting my keyboard off for thinking only about the
> implementation problems as opposed to its benefits.
I'm sure you're not the only person who has thought "Hey, screen scraping t
On Sunday 23 April 2006 12:05, Shlomi Fish wrote:
> This debate demonstrates why a plugin system is necessary for a test
> harness.
No, it demonstrates why a well-defined test output protocol is useful.
-- c
On Sunday 23 April 2006 12:46, Shlomi Fish wrote:
> I agree that a well-defined test output protocol is useful. However, are
> you implying that assuming we have that, one can write several different
> test harnesses to process such test outputs? (I'm just guessing.)
No.
> Wouldn't that imply du
On Sunday 23 April 2006 15:46, Michael Peters wrote:
> How about a good TAP parser module that does nothing but parse TAP. Then
> it could be used in all kinds of test harness permutations.
That's exactly what I want and precisely why I think a well-defined TAP is
more important than a plugin sy
On Monday 24 April 2006 07:56, Michael Peters wrote:
> Not only would this make it easier to have a harness look for something
> other than TAP (maybe some other protocol from some other language) but
> it also means I can parse test runs after they've been run on a
> completely different machine
On Saturday 29 April 2006 18:36, Fu, Elva wrote:
> Hi all, I am a newbie for Perl. I found there are many test modules on
> CPAN. It seems some of these test modules are test frameworks, and you
> can add new test cases to test your code. Some of these test modules are
> used to test Perl itself s
On Saturday 29 April 2006 20:23, Fu, Elva wrote:
> It seems I didn’t express my question very well:-), please let me clarify
> it more detail:
No, I understood you. You have a binary distribution of Perl packaged by
someone besides the official Perl release manager. The package provided by
th
On Tuesday 23 May 2006 07:35, Chris Dolan wrote:
> is_prereq is usually a proxy metric for software maturity: if someone
> thinks your module is good enough that he would rather depend on it
> than reinvent it, then it's probably a better-than-average module on
> CPAN.
Contra: File::Find.
On Sunday 28 May 2006 13:48, Michael G Schwern wrote:
> More importantly, the statistics gathered would help an author to determine
> who, if anyone, is using their module and on what platforms and guide their
> development. What versions of Perl does one have to support? What
> platforms? Do I
On Tuesday 30 May 2006 12:08, Nicholas Perez wrote:
> Why not compare signatures? Is that not feasible?
Which signatures? Is it important that the code comes from the same place
(check the CV properties) or that the code has bound to the same lexicals
(PadWalker) or that the lexicals are in th
On Thursday 29 June 2006 07:26, Michael Peters wrote:
> This is a general problem with the way some of the testing modules work.
> They output their diagnostic messages as comments to STDERR. They should
> send them instead to STDOUT so that it can be synced. TAP does support
> comments, so I'm no
On Saturday 01 July 2006 14:24, Shlomi Fish wrote:
> I'd hate to see some duplicate effort.
Test::Run has really curious licensing; I'm not interested in redistributing
that code under all of those licenses.
-- c
On Saturday 01 July 2006 14:52, Michael G Schwern wrote:
> There are at least two approaches I could think of that fit the
> existing design. One is to replace the tokenizer. The other is to
> create a TAP source which converts from your protocol into TAP. The
> latter is probably easiest and s
On Saturday 01 July 2006 16:46, Fergal Daly wrote:
> It looks like it's only one level of nesting. Any reason not to go the
> whole hog with something like
>
> ..1
> OK 1
> ..2
> ...1
> OK 2
> OK 3
> ...2
> OK 4
> ..3
> OK5
No one has provided an actual use case for it yet. YAGNI.
-- c
On Monday 03 July 2006 09:12, Ovid wrote:
> I am tempted, but there are some problems with parsing TAP output as it
> currently stands. I can write a grammar for it, but the grammar can easily
> produce some output which doesn't make sense.
Isn't this the syntactic/semantic problem common to all
On Monday 03 July 2006 09:01, Jonathan T. Rockway wrote:
> That said, I would be interested. I'm still trying to page all the
> perl6/parrot grammars (PGE, TGE, etc.) into my brain, so any additional
> examples would helpful, interesting, and fun. For me, anyway :)
Jerry Gay just wrote a PGE TA
On Wednesday 05 July 2006 12:28, Shlomi Fish wrote:
> I'd like to suggest a generic proposal for the Perl Foundation Grants. Note
> that I'm not going to take it myself, because I just started a new job and
> would like to commit to it. However, I can be the mentor for this grant.
> I'm posting it
On Wednesday 05 July 2006 14:04, Andy Lester wrote:
> On Jul 5, 2006, at 3:55 PM, chromatic wrote:
> > You want TPF to pay some unspecifed and unidentified other person
> > to continue a fork of a core module that can't ever replace the core
> > module because of its
On Wednesday 05 July 2006 15:02, Shlomi Fish wrote:
> Test::Run is licence-compatible with the core.
I do not think those words mean what you think they mean.
> Some of Test::Run is
> licensed under the GPL and Artistic (version 1.0) licence which is the
> licence of the perl 5 core. The other
On Wednesday 05 July 2006 23:02, Shlomi Fish n wrote:
> I don't see using the X11 licence for my software as anti-social. Like I
> said, anyone can easily fork it as a software of a different licence.
Supposing you actually find a mentee and TPF actually does fund this project
and this code is s
On Friday 07 July 2006 08:56, Shlomi Fish wrote:
Shlomi, you are NOT reading or comprehending what people say here.
Please stop and think about what I write until you understand it before you
respond.
> What I wanted to say is that people should have the
> minimal knowledge to understand that M
On Monday 10 July 2006 10:19, Michael G Schwern wrote:
>got: this
>expected:that
"got" still sucks. Is there any chance to change it to "received"?
-- c
On Monday 10 July 2006 11:41, David Wheeler wrote:
> It's not a gift package delivered by FedEx. What sucks about "got"?
It's the grammatical equivalent of tucking your shirt tail into your underwear
before trying to get a date at your family reunion.
-- c
On Monday 10 July 2006 15:28, demerphq wrote:
> On 7/10/06, Paul Johnson <[EMAIL PROTECTED]> wrote:
> > Whilst I would also like to see something nicer that "got", I'm actually
> > more concerned about the ordering. I always expect to see "expected"
> > first, followed by "got" or "received" or
On Thursday 13 July 2006 08:52, Jonathan Rockway wrote:
> Nobody reads the raw TAP output!
I would love to see your TAP diagnostic parser and reporter. I, unfortunately,
don't have one and must read the raw TAP output myself. :)
-- c
I asked "How does a programming language stagnate?" a couple of weeks ago.
Peter Scott responded with wisdom, in particular:
Modules like SUPER and NEXT are pragmata designed to make Perl behave
the way
we (for large values of "we") think it should have behaved to begin with.
Attribut
On Thursday 13 July 2006 13:32, A. Pagaltzis wrote:
> I thought that’s called “the core distribution.” NEXT is already
> in there. So is List::Util (a big deal for me).
Maybe for Perl 5.9.x... but how long will it be between someone
realizing "Hey, SUPER should have been in Perl 5 from the start
On Thursday 13 July 2006 15:40, A. Pagaltzis wrote:
> People would install these modules anyway even if they
> never get into core or a Bundle::PerlPlus, if they knew that
> these modules are important to them in the first place.
That's really the point. Instead of saying, "Go install X and Y an
On Thursday 13 July 2006 23:37, H.Merijn Brand wrote:
> If I got it right, the wish that was expressed is more like the wish for
> an installer with a GUI.
Nope, just for a nice, easily-installable bundle of modules that work around
the unpleasant backwards compatibilities and warts of Perl 5.
On Friday 14 July 2006 08:18, David Golden wrote:
> Or, perhaps we need the "Perl CPAN Cookbook" -- which would be like the
> Cookbook but focuses *only* on the greatest-hits modules across all the
> same categories. If CPAN is one of Perl's greatest strengths, shouldn't
> that get more attention
On Friday 14 July 2006 12:27, Jonathan Rockway wrote:
> A book like this is something that's been in the back of my mind for a
> while. If there were real interest in this topic (and I think there
> is), I would be happy to help out in a significant way, like writing
> several chapters.
>
> If so
On Friday 14 July 2006 17:59, Andrew Savige wrote:
> I thought Chromatic might be the name of chromatic's father or older
> brother.
No, that's Mixolydian and Ionian, respectively.
-- c
(Yes, of course my mother is Dorian. What were you thinking?)
On Saturday 15 July 2006 11:35, Ovid wrote:
> If the docs are updated to indicate that the skip message must not consist
> solely of a positive integer, then we're OK. Will that break anything out
> there?
Perhaps if you check both arguments, and then issue a warning if the first
looks solely n
On Saturday 15 July 2006 14:43, Ovid wrote:
> By default, it would also provide the Test::More tests but it should also
> normalize sub behavior:
>
> can_ok $proto, $method, $description;
> isa_ok $instance, $class, $description;
> skip $number, $description;
>
> Just doing this:
>
> use
On Monday 17 July 2006 05:19, demerphq wrote:
> The fact that it does the same thing every time for a given set of
> input doesnt mean that it does the RIGHT thing. And i dont see how its
> possible to automatically do the right thing every time. Therefore if
> you need a custom wrapper you need t
On Monday 17 July 2006 11:37, Ovid wrote:
> For example, what could be done in TAP::Harness to improve the reporting on
> line numbers? That alone would be a nice benefit for folks.
I agree, but I disclaim the idea that there's a nice, general, working
heuristic.
The best I've come up with che
On Tuesday 18 July 2006 15:57, Jonathan Rockway wrote:
> 2) Get M::I into the core of perl, so that everyone has a known-good
> tested-everywhere version.
For various values of "everyone" and "everywhere" perhaps.
> Actually now I see a third resolution: don't use M::I for CPAN modules.
> CPAN (
On Tuesday 18 July 2006 17:28, Jonathan Rockway wrote:
> If you really don't want to have test names, you can specify undef. But
> making them "required" (as in "before everything else") makes the API
> easier to use for people who are doing things right (i.e. naming their
> tests).
That's beggi
On Wednesday 19 July 2006 06:03, demerphq wrote:
> Excuse me? Where did I say the code was "broken"?
Wasn't that the implication when you said you've seen misleading line numbers
many times?
> use Test::More tests => 3;
>
> sub my_ok {
> ok($_[0],$_[1]);
> }
I don't know why you'd expect t
On Wednesday 19 July 2006 09:28, Fergal Daly wrote:
> On 19/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > On Wednesday 19 July 2006 06:03, demerphq wrote:
> > > sub my_ok {
> > > ok($_[0],$_[1]);
> > > }
> > I don't know why you'd e
On Wednesday 19 July 2006 10:01, Fergal Daly wrote:
> Let me rephrase that. What's wrong with the author's expectation that
> he can use the his standard programming toolkit and get sensible
> results?
>
> Something is broken but I don't see why it must be the test script.
Perhaps then the expect
On Wednesday 19 July 2006 15:17, demerphq wrote:
> On 7/19/06, chromatic <[EMAIL PROTECTED]> wrote:
> > > Excuse me? Where did I say the code was "broken"?
> >
> > Wasn't that the implication when you said you've seen misleading line
> &g
On Wednesday 19 July 2006 10:35, Fergal Daly wrote:
> A correctly documented bad user experience is still a bad user
> experience. What possible justification is there for not being able to
> easily use subroutines in test scripts?
Who broke your fingers? You can use subroutines in test scripts.
On Wednesday 19 July 2006 18:10, Fergal Daly wrote:
> On 20/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
> > > Simple question. Given this code:
> > >
> > > sub foo {
> > >
On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
> Simple question. Given this code:
>
> sub foo {
> my $thing;
> is($thing->x(), "x"); # line 4
> is($thing->y(), "y");
> }
>
> $t1 = Thing->new(1);
> foo($t1); # line 9
> $t2 = Thing->new(2);
> foo($t2);
>
> lets say the first
On Thu, Jul 20, 2006 at 01:38:46AM +0200, demerphq wrote:
> Now i consider "wrong" to be different from "broken" or "buggy". To me
> broken and buggy mean that the reporting doesnt do what its supposed
> to do. But since I know that what its supposed to do is report where a
> given Test::Builder b
On Thursday 20 July 2006 02:59, Fergal Daly wrote:
> > There already exist two long-accepted, well-understood, coded, tested,
> > and debugged ways to answer both questions. I don't see the value in
> > adding a third, especially when it's not substantially better than either
> > and can be wrong
On Thursday 20 July 2006 13:05, Adriano Ferreira wrote:
> Sometimes, I would like to
> have something like that below so that I don't need to think about how
> to compute the number of tests beforehand
I don't understand this. I have a Vim macro that switches between:
use Test::More 'no
On Thursday 20 July 2006 13:50, Fergal Daly wrote:
> Example code please.
You *quoted* my example code in multiple messages, including this one.
> You're saying there's a situation where using
> $Level produces the incorrect output. I'm saying there isn't.
I don't know what else to call a stac
On Thursday 20 July 2006 14:46, Fergal Daly wrote:
> Your example does not produce any incorrect output.
Perhaps "incorrect" is a very poor word choice, but I certainly consider the
stack trace behavior potentially unhelpful and potentially misleading.
I will make one more attempt to demonstrat
On Thursday 20 July 2006 16:01, Michael G Schwern wrote:
> On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > If I am not mistaken the problem with no_plan is that the test script
> > might exit before actually running all the tests you wanted and Harness
> > won't notice it.
> PS In all my
On Thursday 20 July 2006 16:57, Fergal Daly wrote:
> On 21/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Test an XS component. Segfaults don't call done_testing_now().
> >
> > Yes, that happened to me last night. Yes, I had 'no_plan' active.
On Friday 21 July 2006 12:14, A. Pagaltzis wrote:
> Of *course* it’s not BEGIN that’s buggy. I was commenting on the
> fact that nothing in T::B/T::M screams bloody murder when you run
> a test before you’ve declared your plan. Assuming I conjectured
> correctly, then if that’s what not a bug, I d
On Friday 21 July 2006 12:17, Andy Lester wrote:
> http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
Half of that is a valid Scheme program.
-- c
On Tuesday 08 August 2006 00:27, Adrian Howard wrote:
> Did we ever figure out if T::H not doing this was a bug or a feature?
I vote bug.
-- c
On Tuesday 08 August 2006 00:30, [EMAIL PROTECTED] wrote:
> Following in the footsteps of the recent discussion on extending no_plan
> to cover the case of us making sure the script actually finished
> 'normally', it occurred to me that another thing that might be useful is
> a means to have Test:
On Tuesday 08 August 2006 18:53, James E Keenan wrote:
> chromatic wrote:
> > I have a vim macro to toggle the counter between 'no_plan' and a number.
>
> Could you share that with us? (Adding to new macros to .vimrc is where
> I'm *really* Lazy.)
On Monday 14 August 2006 17:20, jerry gay wrote:
> > I've added the plan for the neutral todo mechanism to Pugs' TASKS
> > file, getting help from many others on #perl6. The new todo marks look
> > like this:
> >
> >todo :pugs<6.28.0>, :p6p5<0.110>, :parrot<1.00>;
> >is $got, $expected; #
On Monday 14 August 2006 18:53, jerry gay wrote:
> moving todo() info out of these test files leads to fragile
> test harnesses, as adding a test to the middle of a file will change test
> numbers. if test descriptions are used, then unique descriptions for each
> test are required. et cetera.
Su
On Monday 21 August 2006 10:20, David E. Wheeler wrote:
> If I were you, I'd assume that silence was a blessing and push on.
I don't know how this blessing might sound, but I do know how the opposite
sounds, and it's much noisier.
-- c
On Monday 04 September 2006 07:12, Rafael Garcia-Suarez wrote:
> What's exactly the problem with sending everything to stdout by default?
> T::H knows how to cope with that.
T::H didn't always know how to cope with that. I patched it within the past
couple of years.
I think it's a long-time ba
On Wednesday 06 September 2006 02:53, Thomas Klausner wrote:
> - buildtool_not_executable
> Check if the buildtool (Makefile.PL, Build.PL) are not executable
> (and thus need to be called with 'perl Build.PL' thereby specifying
> which exact version of Perl you want)
I'm not sure of the val
On Wednesday 06 September 2006 10:27, Jonathan Rockway wrote:
> I could be wrong here, but I think the check is to make sure that tar
> doesn't set +x on Makefile.PL or Build.PL, thus forcing the user to run
> the proper version of perl instead of automagically running the perl
> that shebang poin
On Thursday 07 September 2006 00:51, Gabor Szabo wrote:
> In one module where we had planty of examples I addeded a script that
> would creata a Module::Name::Examples.pm that is a collection of the
> example files in pod format. This modules gets installed so the examples
> are right at hand.
>
On Thursday 07 September 2006 03:28, Gabor Szabo wrote:
> On 9/7/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Pod::ToDemo, for example?
>
> Sort of but not exactly.
>
> As I can see in the SDL::Tutorial where Pod::ToDemo is in use,
> there can be only one exam
On Tuesday 12 September 2006 21:37, Michael G Schwern wrote:
> (For the sarcasm impaired, if you're just going to store the whole
> post-install source tarball you might as well just grab it from CPAN again)
I believe you meant to say BackPAN.
-- c
On Wednesday 13 September 2006 23:35, Ovid wrote:
> Since the parser is not supposed to do anything with junk lines, I assume
> that junk after the plan is also allowed? For right now, I'll assume it's
> not and just add support later.
>
> ok 1
> not ok 2
> 1..2
> # this comment i
On Thursday 14 September 2006 13:14, Ovid wrote:
> What's 'bonus'? I haven't figured that out yet.
That should be the number of successful TODO tests. If it's not, I have no
idea.
> Also, I never tracked the exit status of the tests. Frankly, I never used
> that number myself. Does anyone?
On Saturday 16 September 2006 01:31, Ovid wrote:
> In this case, Test::Harness and friends report that 'ok 9 # todo' is
> passing, not failing, but I'm reporting the opposite result. I think my
> behavior is more correct because I'm trying to write things so that someone
> who forgets writes a ba
On Saturday 16 September 2006 14:42, Fergal Daly wrote:
> So, a passing TODO tells me that either the author
> - writes bad tests
> - means something else entirely by TODO
> - didn't run the test suite before this release
I can buy these, to some degree.
> or
> - my environment is different to t
On Monday 18 September 2006 03:26, David Golden wrote:
> I think authors need to aim to have the quality of test code be the same
> as the quality of module code. (Though I'll admit that I don't always
> live up to that standard myself.)
At some point, this ought to be a major goal of Perl QA.
On Wednesday 20 September 2006 07:53, demerphq wrote:
> On 9/20/06, Smylers <[EMAIL PROTECTED]> wrote:
> > If you get a reference to a blessed object and that object has
> > overloaded stringification then please just treat it as a string, not a
> > reference.
> You of course are aware of what a
On Wednesday 20 September 2006 14:35, Fergal Daly wrote:
> HOW CAN THIS POSSIBLY BE A GOOD THING? Compare it with the case where
> we make them real tests
>
> - a prefectly clear run means nothing is broken
> - a run with failures means something is broken
>
> which is exactly how life should be.
On Friday 22 September 2006 08:51, David E. Wheeler wrote:
> I think that if Ovid hacked Test.pm, then he'd have a 99.99%
> solution. Good enough, no?
The authors of affected distributions could also switch to the
Test::Builder-based Test.pm compatibility module, if I could remember its
name.
On Saturday 23 September 2006 11:30, A. Pagaltzis wrote:
> * Fergal Daly <[EMAIL PROTECTED]> [2006-09-23 19:35]:
> > At least then the user knows there's a problem _before_ he
> > . Remember,
> > this thread is about how the toolchain is really for the user's
> > benefit. Hiding failures to avoid
On Monday 25 September 2006 02:41, Florian Scharinger wrote:
> I have troubles building Test-Simple-0.64 on a standard SL3 machine:
>
>perl Makefile.PL
>make
>make test
>
> several threading related tests fail, e.g.:
> -
> t/threads.Thread 1 terminated abnormall
I read a lot of documentation for CPAN modules and find a fair few typos. Yet
making patches for the POD is a hassle; I would have to download the archive,
uncompress it, copy the file, fix the typo, generate a patch, and submit it.
Wouldn't it be nice to be able to pull up a text entry box onl
On Wednesday 04 October 2006 20:36, Ivan Tubert-Brohman wrote:
> I couldn't resist the temptation and started working on this feature.
> It's almost done now, I think it should be up by tomorrow or Friday.
No one has said this in a while, so:
Thank you! Great work!
-- c
On Thursday 05 October 2006 12:25, Christopher H. Laco wrote:
> I'm having a idiot moment...
>
> I'm trying to mock out some config reading tests for reading from
> MP1/MP2 even though I don't have either installed. so I thought
> "Test::MockObjext is the answer!".
>
> The following code goes boom
On Thursday 05 October 2006 12:48, Christopher H. Laco wrote:
> I won't pretend not be be confused at the moment then, because I have
> other tests that do:
>
> T::MO->new->fake_module('Foo'), and classes that 'use Foo' and do
> 'Foo->new' just work with the mocked verson. At least, I thought they
On Wednesday 25 October 2006 07:41, Adam Kennedy wrote:
> I guess the tricky bit is measuring it, do we just look for -T in the
> test scripts?
>
> If we add this, it's definitely going to hurt me in the game, but I
> think it might be worth it.
This may be a new Kwalitee metric worth updating ol
On Thursday 26 October 2006 07:37, Paul Beckingham wrote:
> To each his own, but my thoughts were not that it takes time to
> parse, or that there is any unreasonable performance issue here -
> just that it is so completely *unnecessary* to say "ok" lots of times.
Crazy thought: don't call ok
On Tuesday 19 December 2006 16:04, Joshua ben Jore wrote:
> It'd be nice if there were a pragma or function for use by
> Devel::Cover which said just that:
Nicer yet would be if Devel::Cover (and I haven't tried in a few months; too
busy with other things, so if there's a fix now, not only will
On Thursday 11 January 2007 06:30, Ovid wrote:
> Quite often people will write code which tests to see if
> $ENV{HARNESS_ACTIVE} is true. For example, this allows them to not
> email support from their code while testing. This variable is set in
> Test::Harness. However, this causes a problem w
On Sunday 21 January 2007 04:50, Randal L. Schwartz wrote:
> Not that it's part of CPAN, but I also have written a magazine article
> or two using Test::Harness::Straps, so it's in the public corpus of
> such usage.
I've spoken and published on it too.
-- c
On Sunday 21 January 2007 10:03, Andy Armstrong wrote:
> On 21 Jan 2007, at 17:59, chromatic wrote:
> > On Sunday 21 January 2007 04:50, Randal L. Schwartz wrote:
> >> Not that it's part of CPAN, but I also have written a magazine
> >> article
> >> or tw
On Tuesday 30 January 2007 12:18, Nadim Khemir wrote:
> Any of the subroutines could croak. So my point is "is there any point in
> using lives_and" at certain places when it's not used in thousands of other
> places?
Sure -- when calling code that you know throws exceptions under certain
circum
On Tuesday 30 January 2007 22:17, Joshua ben Jore wrote:
> Then you can't use ref() because that return all kinds of wrong values.
Someone ought to put that on temporary tattoos and hand them out at every YAPC
for the next five years.
-- c
On Thursday 01 February 2007 13:37, Joshua ben Jore wrote:
> I'd be a happy guy if a paranoid T::E caused consternation and people
> to post "OMG! My stuff fails now!" to perlmonks or whatever.
Be very careful with that. I fixed a bug in Test::MockObject a while back and
a few people yelled ver
On Thursday 01 February 2007 23:23, Gabor Szabo wrote:
> Can I use TAP for this? Can TAP be used to represent such hierarchy?
Filesystem directories already represent a hierarchy. I leave the
implementation as a (trivial) exercise for the reader.
-- c
On Tuesday 13 February 2007 08:24, Ovid wrote:
> Really? :)
>
> java.lang.NullPointerException
Oh please, everyone knows Java doesn't have pointers!
-- c
OT - there are a lot of definitions of fixtures. The best I've found
is "stuff tests share", which is exactly what Skud said.
On Thursday 22 February 2007 12:53, Andy Lester wrote:
> Would there be an option to specify where to find the mocked libs,
> rather than assuming t/lib?
But:
use mocked 't/some_other_lib/' SomeModule;
... isn't all that much shorter than:
use lib 't/some_other_lib';
us
On Thursday 22 February 2007 23:21, Ovid wrote:
> --- Luke Closs <[EMAIL PROTECTED]> wrote:
> > Plus, I'm trying to get this t/lib mocking meme going. :)
>
> Except that I am already using t/lib for a bunch of other helper
> modules I use in our testing code. Telling me "you can only use t/lib
>
On Saturday 24 February 2007 06:47, Eric Hacker wrote:
> Is it OK to have the return value from a test be something more than
> just true when a test passes? Thus the test might be used as a right
> value in the test script.
Seems like, in general, the semi-predicate problem. What if the value b
201 - 300 of 518 matches
Mail list logo
