* Gabor Szabo <[EMAIL PROTECTED]> [2007-07-24 08:45]:
> That is, there is a phase where I setup the test environment
> and then there is the actual test. Obviously each phase can
> consists of several ok() functions.
Right. The setup phase is called the “fixture” in testing lingo
and it should not
Gabor Szabo wrote:
So does that mean others are not interested in separate reporting of
"thing is broken" vs "could not even execute test"
I'm very much interested in it. I've not been following the rest of
this thread, but if you're talking about reporting things like XS
modules not compil
SKIP might be a good idea to avoid running tests that cannot work due
to some missing prereq or bad environment or whatever but it still
does not solve the
reporting problem.
There can be calls like this
ok($ok, "environment is ready");
and calls like this
ok($ok, "system under test works well
On 7/24/07, Adam Kennedy <[EMAIL PROTECTED]> wrote:
He's doing it within a single test script, BAIL_OUT is for the entire
series of test scripts.
"die" is BAIL_OUT for a single test :)
That works. Or use a SKIP block.
David
David Golden wrote:
On 7/24/07, Gabor Szabo <[EMAIL PROTECTED]> wrote:
In the way it is written now both setup-phases-failure and
real-failure are displayed in the same way.
When it fails I know something went wrong but I don't know if
it is in the test environment (e.g. not enough disk space) o
On 7/24/07, Gabor Szabo <[EMAIL PROTECTED]> wrote:
In the way it is written now both setup-phases-failure and
real-failure are displayed in the same way.
When it fails I know something went wrong but I don't know if
it is in the test environment (e.g. not enough disk space) or it is
in the produc
Hi,
I have a test that looks like this:
ok(prepare_first(), "first prepared");
ok(test_first(), "first is working");
ok(prepare_second(), "second prepared");
ok(test_second(), "second is working");
That is, there is a phase where I setup the test environment
and then there is the actual test.