- Original Message
From: Nicholas Clark <[EMAIL PROTECTED]>
> There is this big hairball of under-tested code. (Nothing new here)
> So the question is, which to tackle first - unit tests, or functional tests.
Enough people have answered that I suspect you have your answer, but I thought
On 6 Aug 2006, at 14:27, Sagar Shah wrote:
[snip]
No, I think you're absolutely right. I've also long held the view
that
functional tests provide a better cost:benefit return.
Unit tests do have their advantages, but if I had to chose between
writing unit & functional tests (say because of r
This is more of a "using Perl code for doing QA" than "doing QA of Perl
code", so apologies if it turns out to be completely off topic...
At OSCON last week I presented an automated test harness called
'Crucible', which we've used for testing the Linux kernel, NFSv4 in a
client-server environment,
Hello everyone,
I have come up with an alternative to specifying the number of tests
while still verifying that they all execute properly. It is my
understanding that the main benefit to taking the time to specify a plan
is to verify nothing funky happened before all the tests were executed
* Daniel Risse <[EMAIL PROTECTED]> [2006-08-08 05:10]:
> So something like this:
>
> use Test::Simple 'no_plan';
> use Test::Terminated;
>
> # insert tests here
>
> # signal we made it to the end okay
> terminated_ok();
It occurs to me that you don’t even need that.
Just do something like the
I definitely like the idea of avoiding the need to call the function at
the end. I might not understand the intricacies of how END blocks work,
but I don't understand how this would work.
Specifically something like this:
use Test::Terminated;
my $is_ok = oops_exit_called();
ok($is_ok);
##
- Original Message
From: Daniel Risse <[EMAIL PROTECTED]>
> To get around this, while still not having to specify the number of
> tests to execute, it is run a test from an END block that fails unless
> the test completed. This would be signified by calling a function on
> the last li
