Re: [RFC/PATCH (WIP)] gitweb: Use Test::WWW::Mechanize::CGI to test gitweb output

From: Lea Wiemann <lewiemann@gmail.com>
Date: Jun 14, 2008, 21:12 UTC
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