From: Lea Wiemann <lewiemann@gmail.com>
Date: Sat, 14 Jun 2008 21:12:27 GMT
Subject: Re: [RFC/PATCH (WIP)] gitweb: Use Test::WWW::Mechanize::CGI to test gitweb output
Message-ID: <4854343B.40707@gmail.com>
In-Reply-To: <200806142059.52373.jnareb@gmail.com>

Jakub Narebski wrote:
> Well, I'd divert stderr in tests cases (or use simply 'test_external'),
> or better filter stderr, only in those cases where there is spurious
> but not dangerous thing on stderr.

Since you can only run whole perl scripts with test_external, we'll have 
to resort to using those discard_/restore_stderr functions.  I doubt 
filtering for specific messages is worth the effort.

> But again, I think the solution would be either to add feature to
> Git.pm, something like command_output_pipe_no_stderr, which would
> redirect stderr to /dev/null,

(FYI, Git.pm has such a feature in the command method, though it it 
simply closes STDERR and doesn't properly re-open it, I believe.)  The 
Git::Repo API I'm writing doesn't currently generate any spurious output 
on stderr, but if it ever does I'll make sure it gets discarded.

>> Since you're accessing http://localhost/ URLs, the web server's PATH is 
>> in effect,...
> 
> It isn't.  http://localhost/ is just access convention,

Yup, I should've read TFM. :)  On my system, $PATH is empty in 
gitweb.cgi for some strange reason, but since using an absolute path for 
$GIT works, I won't track it down for now.

> [*1*] it would be nice to have perl_application in WWW::Mechanize::CGI,
> which would simply setup %ENV and use do() instead of system() on
> provided application.

Gitweb and probably CGI::Carp qw(fatalsToBrowser) use 'exit', so we'd 
have to use Test::Trap (or so) to catch those.  I think we should defer 
this until performance actually becomes an issue.

-- Lea