Re: [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 5, 2007, 21:02 UTC
Message-ID: <200712052202.27111.jnareb@gmail.com>
In-Reply-To: <7v7ijsq5zm.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 14 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > It would be quite easy I think to add checking if gitweb returns
> > expected HTTP return code (HTTP status). So what is the portable way
> > to check if first line of some output matches given regexp (given fixed
> > string)?
> 
> Huh?  Wouldn't something like this be enough?
> 
> 	>expect.empty &&
> 	cmd >actual.out 2>actual.err &&
>         diff -u expect.empty actual.err &&
>         first=$(sed -e '1q' <actual.out) &&
> 	test "z$first" = "I like it"

Well, actually that is even better idea. We can go for one of the three levels of HTTP status checking:

1. Check if we got "Status: 200 OK" when we expect it, and not have it
   when we expect other HTTP status, e.g. when requesting nonexistent
   file. The above code is enough for that.

2. We can check if we got expected status number, for example 200 for
   when we expect no error, or 404 when object is not found, or 403
   if there is no such object etc. I was thinking about using this version
   the need to check not full first line, but fragment of it.

3. We can check full first line, for example
     Status: 200 OK
     Status: 403 Forbidden
     Status: 404 Not Found
     Status: 400 Bad Request
   but this might tie gitweb test too tightly with minute details of
   gitweb output. The above code is good for that too.

What do you think, which route we should go in test?

-- 
Jakub Narebski
Poland