git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lea Wiemann <lewiemann@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
Date: Fri, 20 Jun 2008 15:49:44 +0200	[thread overview]
Message-ID: <485BB578.3040605@gmail.com> (raw)
In-Reply-To: <200806201408.05254.jnareb@gmail.com>

Jakub Narebski wrote:
> First, it is not XML validation[*1*], but check if XML is well-formed.
> Second, I think it would be better if adding XML checks (RSS, Atom,
> OPML) would be left as separate commit.

Sure; FWIW I'm generally in favor of having a large initial commit for 
new independent files (and since we don't need to worry about conflicts 
I'm not fervent about getting this into the next branch ASAP), but we 
can definitely add XML checking separately.

>> +# set up test repository
> 
> I have created this part as a copy of older t9500 gitweb test, thinking
> about what we might want to test, but the WIP of Mechanize based t9503
> doesn't have yet tests for those specific features.

I was thinking about that.  Right now the tests are so generic that you 
can replace the test repository with anything else as long as it has 
some commits (and later some tags, etc.).  That's kinda nice.

>> +# We don't count properly when skipping, so no_plan is necessary.
>> +use Test::More qw(no_plan);
> 
> Actually it is not that we cannot could properly when skipping, because
> there are two ways to have skipped tests and test count upfront,

We're skipping tests if a page-load fails to prevent a slew of failure, 
using constructs like if(test_page '?...') { ... inspect the page ...}. 
It's my impression that we shouldn't end up with a wrong test count even 
if one test fails; but then we'd have to replace those ifs with 
cumbersome skip blocks.

I'm generally not in favor of maintaining any test count plans; they're 
an unnecessary failure source, and I don't think they buy us much, if 
anything -- correct me if I'm missing something Perl-specific here.

> Why do you use shortened SHA1 identifier, instead of full SHA1?
> Links in gitweb use full SHA1.

That's for readability in the test output; links get checked anyway, 
don't they?  If you think we should be testing against full SHA1s, 
that's fine too.

> Errr, HEAD would be $revisions[0], $revisions[-1] would be $root.

Fixed, thanks.

> Another solution would be to copy relevant parts of cgi_application
> (without all the checks for example), and use $mech->cgi( sub { ... } );
> here (without the cgi_application bug).

ISTR that using cgi(sub ...) gives us problems with untrappable exits in 
gitweb.cgi (and possibly more things), right?  I'm fine with the 
workarounds we have in place, they don't seem brittle.

>> +our $baseurl = "http://localhost";
>> +our($params, $url, $pagedesc, $status);
> 
> I think we can use 'my' here;

They're used in subroutines, so I believe 'our' is correct here.

> Style: I would write "our (", with space [...]

>> +# if (test_page '?p=.git;a=summary', 'repository summary') {
> 
> Style: I would use function call form, i.e. "test_page(...)", not
> command-like (or script-like) form.

Both fixed, thanks.

> As to the rest of the test: I think as preliminary test it is a good
> thing to have.  We can think about what tests to add later (unless you
> rather have exhaustive test suite now...).

I'll be writing tests as I go and change parts of gitweb.  I won't be 
able to write exhaustive tests, but I at least want to make sure that 
the code I'm changing is covered somehow.

-- Lea

  reply	other threads:[~2008-06-20 13:50 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-14 12:47 [RFC/PATCH (WIP)] gitweb: Use Test::WWW::Mechanize::CGI to test gitweb output Jakub Narebski
2008-06-14 14:40 ` Lea Wiemann
2008-06-14 18:07   ` Jakub Narebski
2008-06-14 18:31     ` Lea Wiemann
2008-06-14 18:59       ` Jakub Narebski
2008-06-14 21:12         ` Lea Wiemann
2008-06-15  8:36           ` Jakub Narebski
2008-06-14 18:18 ` Lea Wiemann
2008-06-14 18:31   ` Jakub Narebski
2008-06-14 23:57 ` [RFC/WIP/PATCH v2] gitweb: add test suite with Test::WWW::Mechanize::CGI Lea Wiemann
2008-06-15 18:01   ` Jakub Narebski
2008-06-15 18:45     ` Lea Wiemann
2008-06-16  0:40       ` Jakub Narebski
2008-06-16  9:10         ` Lea Wiemann
2008-06-16 20:15           ` Jakub Narebski
2008-06-20  3:18   ` [WIP/PATCH v3] " Lea Wiemann
2008-06-20 12:08     ` Jakub Narebski
2008-06-20 13:49       ` Lea Wiemann [this message]
2008-06-20 18:03         ` Jakub Narebski
2008-06-20 22:04           ` Lea Wiemann
2008-06-20 22:18             ` [WIP/PATCH v4] " Lea Wiemann
2008-06-23  0:45               ` [PATCH v5] " Lea Wiemann
2008-06-23  1:14                 ` [PATCH v6] " Lea Wiemann
2008-06-23  2:30                   ` Junio C Hamano
2008-06-23  7:00                     ` Lea Wiemann
2008-06-23 13:31                   ` Jakub Narebski
2008-06-23 17:57                     ` Lea Wiemann
2008-06-23 22:18                       ` Jakub Narebski
2008-06-24  2:01                         ` Lea Wiemann
2008-06-24  2:18                           ` [PATCH v7] " Lea Wiemann
2008-06-26 13:47                             ` [PATCH] " Lea Wiemann
2008-06-26 13:48                             ` [PATCH v8] " Lea Wiemann
2008-06-29 22:47                               ` Jakub Narebski
2008-06-29 23:39                                 ` Lea Wiemann
2008-06-29 23:56                                   ` Jakub Narebski
2008-06-30  0:30                                     ` Lea Wiemann
2008-06-30 21:55                                       ` Jakub Narebski
     [not found]                                 ` <48681EC8.8000606@gmail.com>
2008-06-30 22:01                                   ` Jakub Narebski
2008-06-24  4:20                       ` [PATCH v6] " Junio C Hamano
2008-06-24  8:37                         ` Lea Wiemann
2008-06-24  9:23                         ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=485BB578.3040605@gmail.com \
    --to=lewiemann@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).