If you get 200, then you will be able to execute your test case; but if you get 400-404 already your first test step will fail.
If during development redirection (301-304) has been introduced, then you'll still get the page thus your app will behave as in case of 200.
So querying the status code would be only a redundant step.
Provide use case(s) and preliminary analysis (benefits, drawbacks) why implementing this would be of advantage.

I want to write tests that:
-verify my program does not give a 404 status code, even if there is a program failure (eg: an exception will catch the error and generate a reasonable response)
-assert that a response page has a status code of 200, even if the user gives a badly formed url

Also:
-if the user gives a badly formed url, I want to assert that the response page is not a 404 status code
-in apache, i can create a custom 404 page: i want to test that the response code is 404 as well as my custom page content is correct
-i don't currently do any redirection, but i can imagine a url that gets redirected depending on it's parameters. in this case, I want to test that the redirection (301, 302) happened without having to test the specific page content that it got redirected to.

Other unit testers provide this:
-twill: code assertion (see http://twill.idyll.org/commands.html )
-simpletest: assertResponse($codes) (see http://simpletest.org/en/web_tester_documentation.html )

This is marked as Resolved, but it doesn't seem to have been?

I too would be interested in viewing the HTTP Status Code from each step, and if possible the HTTP headers. This isn't possible to get from the browser via JavaScript, however with RC, since all the requests go via the proxy, it should be possible to capture them and then return them in response to (new) API calls from the client driver. As Dennis points out, this is available in other frameworks/ test engines, so it would be good to support it.

Is this something that you're looking at, or have you decided that it's not needed?

I'm happy to help if I can with this development.

This issue has the status "Resolved" with the resolution "Incomplete": Still no meaningful use case has been provided.
Instead of checking the HTTP response you should make assertions on the content of the page - this is what the user faces and not the codes. Furthermore, consider reading Google's recommendation on "soft 404's": http://googlewebmastercentral.blogspot.com/2008/08/farewell-to-soft-404s.html.

This may put the cat amongst the pigeons.
I have to test for ads appearing on my site's web pages; just to check whether they appear or not.
As you may know, the actual ad appearing at runtime may be anything, sourced from different servers having varying types of content.

I feel the best method to test these would be to gather the status code of the ad URL.
If the URL throws a 404, I can be certain there is a problem. Ad URLs seldom throw a soft 404.

If anyone has alternative means to test my "predicament", lemme know.

Thanks for the posting about Hard v Soft result codes, however there are still two issues:

1. As Aniket points out not all content/servers are under the control of the person running the test. The content may be variable, so you can't always say what you expect, but of course you know what you don't want - a 404, or 500.

2. For servers where you are in control, and can set result code/content, you could check the content to see if what was expected did arrive, but if it didn't, then it's useful to be able to report and diagnose based on the result code.

Is there a template of what you need from a 'meaningful use case', so that if you still need one I can prepare on.

Patrick, please update this issue according to your implementation.

Meaningful test case:

The site I'm testing uses a lot of "virtual" URLs – things which appear to be files and directories as somebody's browsing around my site, but "under the hood" are all generated by one master handler script. This handler code is what I'm testing. There are a few scenarios it needs to perform correctly, and the status codes need to be checked because it's my handler code, not the webserver that's calling it, which is setting the status.

1. The page exists: www.example.com/this-exists.html should serve the page, and show a 200 status

2. The page doesn't exist: www.example.com/this-doesnt-exist.html should show the site's "page not found" content, and have a 404 status

3. Permanent URL change or URL canonicalization: www.example.com/old-location.html should be redirected to www.example.com/new-location.html; we need to verify that this happened with a 301 permanent redirect status code. This tells Google and other search engines that any page rank, summary text, inbound links, etc. associated with the old /old-location.html URL should be transferred to the /new-location.html

4. Temporary URL change: some feature on my site is down for upgrades; everything under www.example.com/some-feature/ should redirect to www.example.com/some-feature/come-back-soon.html with a 302 redirect status code. This tells Google and other search engines to come back and try the URL later, and NOT to update the page rank, summary text, etc of the pages under /some-feature/ with the "this feature is down for upgrade; come back soon!" content that's currently being served.

I too hope this functionality can be added. Perhaps in many situations it isn't needed, but overall it seems like basic enough functionality to justify having in the API. This is an area too complex and messy to be very prescriptive about.