2009/3/16 Michael G Schwern :
> Fergal Daly wrote:
>> Alternatively, the plan is a meta-test, a test for your testing code.
>> It is the equivalent of putting
>>
>> is($tests_run_count, $tests_i_planned_count)
>>
>> at the end of your test script. Letting the computer calculate the
>> plan is the e
On Mar 16, 2009, at 6:25 PM, Michael G Schwern wrote:
Ok, write it.
Fair enough. http://www.perlfoundation.org/perl5/index.cgi?
test_counts is the start.
I don't mean to stomp on new discussion, just the rehashing of the
old. My apologies if my skimming of the thread conflated the two
Fergal Daly wrote:
> Alternatively, the plan is a meta-test, a test for your testing code.
> It is the equivalent of putting
>
> is($tests_run_count, $tests_i_planned_count)
>
> at the end of your test script. Letting the computer calculate the
> plan is the equivalent of putting
>
> is($tests_r
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Monday 16 March 2009 11:47:
>
>> I suppose what really covers their ass is that by being broken up into
>> test_* routines each test function is isolated and their code is
>> simpler and less likely to have a logic error that results in a test
Great idea. Why didn't someone think of it before and refer to that
page in the first posting in this thread and also in the middle...
F
2009/3/16 Andy Lester :
>
> How about we put up a page somewhere that discusses the pros and cons of
> counting tests, and then whenever the quarterly discussio
Andy Lester wrote:
>
> How about we put up a page somewhere that discusses the pros and cons of
> counting tests, and then whenever the quarterly discussion of LOLZ YOU
> ARE COUNTING YOUR TESTZ FOR NO REASON! vs. YOU DON'T KNOW WHAT HAPPENS
> WITHOUT A PLAN N00B! rears its head, we can refer peop
How about we put up a page somewhere that discusses the pros and cons
of counting tests, and then whenever the quarterly discussion of LOLZ
YOU ARE COUNTING YOUR TESTZ FOR NO REASON! vs. YOU DON'T KNOW WHAT
HAPPENS WITHOUT A PLAN N00B! rears its head, we can refer people there.
Some peopl
2009/3/16 Evgeny :
> Thing is. It just does not matter THAT much.
> The case you describe is fairly rare in the xUnit world, or in any
> world I would guess.
And as I said, I got bitten by it just last week. Another way I've
been bitten is when I've done slightly more complex xUnit stuff where
I c
# from Michael G Schwern
# on Monday 16 March 2009 11:47:
>I suppose what really covers their ass is that by being broken up into
> test_* routines each test function is isolated and their code is
> simpler and less likely to have a logic error that results in a test
> never being run.
Why is it
Evgeny wrote:
> The know:
> - how many unit tests were executed each run
> - how much time each unit test took to run (and the total time)
> - which unit tests passed, and which failed
> - the behavior of some tests over time (a bad test can randomly
> fail/pass for example)
As an aside, have a lo
Adrian Howard wrote:
>
> On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
> [snip]
>> The test numbering exists to ensure that all your tests run, and in
>> the right
>> order. XUnit frameworks don't need to know the number of tests
>> because they
>> simply don't have this type of protection.
Thing is. It just does not matter THAT much.
The case you describe is fairly rare in the xUnit world, or in any
world I would guess.
The testing suite does not have a "will", it is only a tool.
When the testing suite works, it just works; When people have
confidence in it for some reason, then th
2009/3/15 Adrian Howard :
>
> On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
> [snip]
>>
>> The test numbering exists to ensure that all your tests run, and in the
>> right
>> order. XUnit frameworks don't need to know the number of tests because
>> they
>> simply don't have this type of prote
On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
[snip]
The test numbering exists to ensure that all your tests run, and in
the right
order. XUnit frameworks don't need to know the number of tests
because they
simply don't have this type of protection. [1]
[snip]
And, to some extent, ne
* Josh Heumann [2009-03-13 14:40]:
> I can change that to:
>
> END {
> pass();
> all_done( 2 );
> }
>
> ...and everything's just fine. The problem really comes when
> the test being run in the END block is in another module (such
> as Test::NoWarnings).
END {
h
* Michael G Schwern [2009-03-14 07:40]:
> Need to come up with a better way to deal with
> end-of-test-process tests.
Add a way in Test::Builder to register callbacks for specific
phases of the output and have TB API client code use that instead
of `BEGIN`/`END` et al.
Regards,
--
Aristotle Pag
16 matches
Mail list logo
