I have a tests JobQueueTest, which tests a queue that can be shared between
processes.
In the tear_down() of JobQueueTest, I want to make sure that the test did not
leave the queue in a lock state (clients that use a JobQueue are not supposed
to ever be able to end up with that kind of locked state).
sub tear_down {
my ($self) = @_;
#
# If a test leaves the queue in a locked state, it's probably a sign
# of an unbalanced lock/unlock pair.
#
$self->assert(!defined($self->{queue}->_already_locked_by_me()),
"This test left the queue in a locked state.\n".
"This is probably a sign that there is an unbalanced
lock/unlock pair somewhere in the code.");
}
The problem is that this assertion ends up masking any failure that may happen
in the course of carrying out the test. For example, if test itself carries out
an assertion that fails with error message X, then instead of seing error X, I
will see the above error message regarding the lock state. This is very
misleading and prevents me from knowing the actual root of the problem.
Is there a way around this? For example, in my tear_down(), could I check to
see if some exceptions have already been raised in this test, and if so, not
assert for consistency of the instance under test?
Thx
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Perlunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perlunit-users
