Bug 28699 - Test Result comes out to be fail if the HTTP response code is non-200's even though the response assertion for the http sampler matches the code.
Test Result comes out to be fail if the HTTP response code is non-200's even ...
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: HTTP
2.0.0
Macintosh All
: P3 enhancement (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-04-29 21:53 UTC by Ryo Sode
Modified: 2005-02-17 19:10 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryo Sode 2004-04-29 21:53:53 UTC
I am not sure if this is the way the software is originally designed to do, at
least one person is extremely annoyed by the fact, because a part of my test
consists of error case handling tests. In other words, I expect that a certain
error such as 404 (not found) comes back and I want my response assertion
element to match that.

Steps:
1. launch JMeter, add a thread group to the root test plan.
2. Under the thread, add an http sampler, View Results in Table listener and
View Results Tree listener.
3. Under http sampler, add a response assertion.
4. In the http sampler, add a valid web server ip address, port#, protocol used.
Then in the path, just enter something bogus like "doesnotexist.htm", assuming
the file does not exist.
5. In the response assertion, choose "Response Code" in the Response Field to
Test. Then in the Patterns to Test table, just have a row with "404". Verify
that Pattern Matching Rule is "Contains".
6. Run the test.
Result: If you look at View Results in Table, the check box column is not
checked, indicating that the test was a failure. If you look at View Results
Tree and expand the tree, you'll see the HTTP Request test shown in red, further
indicating that the test was a failure. If you look at the HTTP response code in
the actual result, you'll see 404. Exactly what we are expecting!
Comment 1 Sebb 2004-06-03 23:06:42 UTC
The current behaviour is correct.

Changing to an enhancement.

A fix for this has been checked into the 2.0 branch.