... but if you are calling prove automatically you should be able to script a wrapper¹ with a timeout.

The advantage would be that this should also be a good place to hard-code corporate wide² policies. :)

footnotes

¹) like "merge_prove.pl" :)

²) and project specific

Hm. How about simply wrapping call to 'prove' into perl script which uses 'alarm' to stop testing process after certain time?

Actually, it makes more sense, to put time-outs in each of the tests. But again, who cares about quality of the tests? I was always wondering, who tests the test scripts :)

Install Time::Limit and then run:

prove -MTime::Limit=60 -Ilib /path/to/tests
[download]

(This works less well if you are using forkprove, but should be fine with the standard prove tool.)

Or in an individual test:

use Time::Limit "30";   # quote marks around the number are required!
[download]

Update: actually it works OK with forkprove, if you get Time::Limit to send its kill signal to the process group:

forkprove -MTime::Limit=-group,60 -Ilib /path/to/tests
[download]

Thanks, that is just what I need.

I will add an overall time-out of half an hour or so to the overall prove run, and then encourage other developers to add a more conservative time-out to each unit test, so that it times out more quickly if there is a bug.

You can do one of 2 things (or both):

a. BAIL_OUT, or

b. check $@ outside of the eval with an ok.

In some case, you may actually want it to time out.

However, that you're timing tells me that what is timing out should probably mocked. It also tells me that you may want to have a more robust wrapper around whatever it is that is timing out - because it may time out when run for real. Throwing Exception::Class is always good - and you can even test that you handle things like timeouts properly using Test::Exception.

A quick and easy way to mock whatever it is that is timing out is to use a typeglob:

# mock returned data
*Package::method = sub { return 'some expected data' };
[download]

# mock a timeout, but wrap this in an eval/alarm
my $a_long_time = 900; # seconds
*Package::method = sub { sleep $a_long_time; return; };
[download]

# mock a die from timeout, but wrap this in an eval/alarm
*Package::method = sub { die "Timed out!\n"; };
[download]

# mock a timeout exception, but wrap this in an eval/alarm
*Package::method = sub { throw My::Exception::Timeout; };
[download]

Thanks, but the issue is not caused by slow connections to external resources. We already mock those. The issue was caused by a bug in normal perl code that had no external dependencies.

What happened, is that the unit test contained code to set-up the initial test data, but that setup code was broken by a change elsewhere in the code base. A bit like:

my @objects = map { My::Object->new() } 1..100;

# Give a random 10 object the bar property, skip any where foo is set.
for( 1..10 )
{
  my $object = $objects[ int rand 100 ];

  redo if $object->is_foo();
  
  $object->is_bar(1);
}

# Use the object array in the unit tests.
[download]

The problem was that someone else changed the default constructor for My::Object, so that foo was always set to true, so the while loop above looped forever.

Nothing to do with external resources, just quick and dirty test code broken by an API change.