Jakub Narebski <jnareb@xxxxxxxxx> writes:
> 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?
4. We should check for what we expect in the parts of gitweb output we
care about. E.g.
* If we are making sure it refuses to serve incorrect request
(e.g. no such repository), we should check for the status, which is
what we care about (we may not care about how the actual error
message is stated).
* Otherwise (and I suspect this is "most of the tests"), we obviously
expect to have "200 OK", and check for that;
BUT IN ADDITION
* If we want to make sure that a specific aspect of the output was
buggy and a patch fixed it (e.g. an href used a short refname
without having refs/heads or refs/tags prefixed, causing
ambiguity), we also should check that part of output in generated
HTML, not just the HTTP status header.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
