Test::Clustericious::Log - Clustericious logging in tests.


version 1.29


 use Test::Clustericious::Log;
 use Test::More;
 use MyClustericiousApp;
 my $app = MyClustericiousApp->new;
 ok $test, 'test description';


This module redirects the Log::Log4perl output from a Clustericious application to TAP using Test2::API. By default it sends DEBUG to WARN messages to note and ERROR to FATAL to diag, so you should only see error and fatal messages if you run prove -l on your test but will see debug and warn messages if you run prove -lv.

If the test fails for any reason, the entire log file will be printed out using diag when the test is complete. This is useful for CPAN testers reports.

In order to control the verbosity of the various logs, you can specify a range of level for each of note, diag and file (file being the log file that is spewed IF the test file as a whole fails).

 use Test::Clustericious::Log note => 'TRACE..ERROR', diag => 'FATAL';

Note that only one set of ranges can be specified for the entire process, so the first module that uses Test::Clustericious::Log gets to specify the ranges. The defaults are somewhat reasonable: the log file gets everything (TRACE..FATAL), note gets most stuff (DEBUG..WARN) and diag gets errors, including fatal errors (ERROR..FATAL).

This module also provides some functions for testing the log events of a Clustericious application.


In order to import functions from Test::Clustericious::Log, you must pass an "import" to your use line. The value is a list in the usual Exporter format.

 use Test::Clustericious::Log import => ':all';
 use Test::Clustericious::Log import => [ 'log_events', 'log_like' ];


 my @events = log_events;

Returns the set of log events for the current log scope as a list of hash references.


 log_context {
   # code

Creates a log context for other Test::Clustericious::Log functions to operate on.


 log_like \%pattern, $message;
 log_like $pattern, $message;

Test that at least one log event in the given context matches the pattern defined by \%pattern or $patter. If you provide a hash reference, then each key in the event much match the pattern values. The pattern values may be either strings or regular expressions. If you use the scalar form (second) then the pattern (either a regular expression or string) must match the events message element.

Note that only ONE message in the current context has to match because usually you want to make sure that particular message shows up in the log, but you don't care if other messages get added at a later time, and you do not want that common type of change to cause tests to break.


 ERROR "Some error";
 INFO "Exact message";
 NOTE "some notice";
 log_like 'Exact message", 'this should pass';
 log_like 'xact messag',   'but this would fail';
 log_like qr{xact messg},  'but this regex would pass';
 log_like { message => 'Exact message', log4p_level => 'INFO' }, 'also passes';
 log_like { message => 'Exact message', log4p_level => 'ERROR' }, 'Fails, level does not match';


 log_unlike \%pattern, $message;
 log_unlike $pattern, $message;

log_unlike works like log_like, except NONE of the events in the current log context must match in order for the test to pass.


Original author: Brian Duggan

Current maintainer: Graham Ollis <>


Curt Tilmes

Yanick Champoux


This software is copyright (c) 2013 by NASA GSFC.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.