FAQ
Hi,

I'm trying to create some tests for my Cat app to make sure the right logging output is being generated in the right place at the right time.

My test case fails, unless I fire off an initial request at the app.

Am using Catalyst::Log::Log4perl v1.02. My Test::Log4perl config is:

log4perl.rootLoggerÞBUG, Screen
log4perl.logger.MyApp.ControllerÞBUG, Screen log4perl.additivity.MyApp.Controller = 0 log4perl.appender.Screen=Log::Dispatch::Screen
log4perl.appender.Screen.stderr=1
log4perl.appender.Screen.layout=Log::Log4perl::Layout::PatternLayout
log4perl.appender.Screen.layout.ConversionPattern=[%d] [MyApp] [%p] %m%n

And this is configured in my cat application:

./lib/MyApp.pm:

__PACKAGE__->setup();
__PACKAGE__->log( Catalyst::Log::Log4perl->new( __PACKAGE__->path_to(__PACKAGE__->config->{path_to_log4perl_conf})->stringify ) );


MyApp::C::TestLogger.pm:

sub index : Private {
my ( $self, $c ) = @_;
$c->log->debug("Starting method index");
$c->log->info("Before body set");
$c->response->body('Matched CatLog4perlTest::Controller::TestLogger index.');
$c->log->warn("After body set");
$c->log->error("A fake error");
$c->log->fatal("A fake fatal error"); }


My failing test cases is ./t/04_test_logging.t:

use strict;
use warnings;
use Test::More;
eval "use Test::Log4perl;";
if ($@) {
plan skip_all => 'Test::Log4perl required for testing logging'; } else {
plan tests => 2;
}

BEGIN {
$ENV{CATALYST_CONFIG_LOCAL_SUFFIX}='test';
}

use Test::WWW::Mechanize::Catalyst 'CatLog4perlTest'; my $mech = Test::WWW::Mechanize::Catalyst->new();

my $tlogger = Test::Log4perl->get_logger("CatLog4perlTest.Controller.TestLogger");

{
Test::Log4perl->start();

$tlogger->debug("Starting method index");
$tlogger->info("Before body set");
$tlogger->warn("After body set");
$tlogger->error("A fake error");
$tlogger->fatal("A fake fatal error");

$mech->get_ok('http://localhost:3000/testlogger', 'index');

Test::Log4perl->end('');
}

This test case fails even though the log output is being printed to screen. However, this is solved by firing an initial request at the app, just after the get_logger() call, which I'm assuming must get everything initialised.

Has anyone else experienced this problem?
Should this be happening in this way and is there a fix or workaround?

I'm trying to test and iron this out prior to rolling out into production.

Thanks,
Anthony

Search Discussions

  • Tomas Doran at Mar 23, 2009 at 3:22 pm

    Anthony Gladdish wrote:
    Has anyone else experienced this problem?
    Should this be happening in this way and is there a fix or workaround?

    I'm trying to test and iron this out prior to rolling out into production.
    I certainly haven't seen this sort of behavior in my applications.

    Can you try reducing the behavior that you're seeing to a test case for
    the Catalyst::Log::Log4perl distribution?

    Cheers
    t0m
  • Sebastian Willert at Mar 23, 2009 at 10:48 pm

    On Mon, 2009-03-23 at 15:22 +0000, Tomas Doran wrote:
    Anthony Gladdish wrote:
    Has anyone else experienced this problem?
    Should this be happening in this way and is there a fix or workaround?

    I'm trying to test and iron this out prior to rolling out into production.
    I certainly haven't seen this sort of behavior in my applications.
    I am noticing this with the latest versions of Log::Log4perl and
    Catalyst::Log::Log4perl. The strangest thing is that the problem
    goes as soon as you use
    Log::Log4perl->get_logger('CatLog4perlTest.Controller.TestLogger')
    You dont even have to start the request.

    Looks like a bug in the interaction between Test::Log4perl and
    Log::Log4perl to me but I haven't found anything in the respective
    change logs that would warrant such a change in behavior.

    I guess Anthony is on the safe side, just issuing the get_logger command
    above before starting the tests.

    Hope that helps,
    Sebastian
  • Sebastian Willert at Mar 23, 2009 at 11:35 pm

    On Mon, 2009-03-23 at 15:22 +0000, Tomas Doran wrote:
    Anthony Gladdish wrote:
    Has anyone else experienced this problem?
    Should this be happening in this way and is there a fix or workaround?

    I'm trying to test and iron this out prior to rolling out into production.
    I certainly haven't seen this sort of behavior in my applications.

    Can you try reducing the behavior that you're seeing to a test case for
    the Catalyst::Log::Log4perl distribution?
    And here are your test cases (against C::L::Log4perl 1.03 and Log4perl
    1.20). Unfortunately it seems like we can't do anything about this on
    our side ...

    Cheers,
    Sebastian
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: 20-test-log4perl.t
    Type: text/troff
    Size: 718 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090324/592cdca4/20-test-log4perl.bin
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: 21-test-log4perl-hotfix.t
    Type: text/troff
    Size: 582 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090324/592cdca4/21-test-log4perl-hotfix.bin
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: 22-test-log4perl-hotfix-broken.t
    Type: text/troff
    Size: 764 bytes
    Desc: not available
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090324/592cdca4/22-test-log4perl-hotfix-broken.bin
  • Anthony Gladdish at Mar 25, 2009 at 2:31 pm
    Hi Sebastian,

    Thanks for your test cases and help with this.
    I'll see if I can glean any more info from the Test::L4p and Log:L4p owners/lists.

    Cheers,

    Anthony

    -----Original Message-----
    From: Sebastian Willert
    Sent: 23 March 2009 23:35
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Using Test::Log4perl, testing cat log output
    only works after firing initial request
    On Mon, 2009-03-23 at 15:22 +0000, Tomas Doran wrote:
    Anthony Gladdish wrote:
    Has anyone else experienced this problem?
    Should this be happening in this way and is there a fix or
    workaround?
    I'm trying to test and iron this out prior to rolling out into
    production.
    I certainly haven't seen this sort of behavior in my applications.

    Can you try reducing the behavior that you're seeing to a test case
    for the Catalyst::Log::Log4perl distribution?
    And here are your test cases (against C::L::Log4perl 1.03 and Log4perl
    1.20). Unfortunately it seems like we can't do anything about this on
    our side ...

    Cheers,
    Sebastian

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 23, '09 at 11:50a
activeMar 25, '09 at 2:31p
posts5
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase