Hamcrest matcher with slashes is interpreted as a part of validation

Question

I have the following validation where I have to check if returned body has a string containing "id": 6354, but it interprets slashes of special characters. How I can validate strings which contain double quotation marks ?

Code

import static org.hamcrest.Matchers.containsString;
import com.jayway.restassured.response.Response;


    response.then()
            .body(containsString("\"id\": 6354"));

Error

Response body doesn't match expectation.
Expected: a string containing "\"id\": 6354"
  Actual: {...,"id": 6354, ...}

What's the code of `containsString`? – Niklas P Aug 21 '15 at 11:29 — Niklas P, Aug 21 '15 at 11:29
@NiklasP I've updated the question, – ashur Aug 21 '15 at 11:34 — ashur, Aug 21 '15 at 11:34
Could you provide an example of the JSON document? – Johan Aug 26 '15 at 18:53 — Johan, Aug 26 '15 at 18:53
How did you fix this? Got the same problem – vanlooverenkoen Mar 12 '17 at 10:38 — vanlooverenkoen, Mar 12 '17 at 10:38

score 3 · Answer 1 · answered Jul 16 '18 at 10:54

3

Hamcrest containsString seems to print the escaped characters in the output error message, however it seems to correctly escape them when doing the matching.

In my example, I was incorrectly adding a space, so following the example in the question: "id": 6354 would give the error Expected: a string containing "\"id\": 6354" however when I changed it to "id":6354", it passed the assertion.

answered Jul 16 '18 at 10:54

Adam Beddoe

153
2
10

I experience the same behavior here with the actual matching working correctly even though the output error message prints the escape characters; as a reference I am using Hamcrest 1.3. Perhaps this behavior is different in a newer version? – risingTide Mar 03 '21 at 17:11

score 2 · Answer 2 · answered Mar 12 '17 at 11:16

2

I think there is something wrong with the escape slash. So I used:

assertTrue(response.contains("\"id\":6354"));

answered Mar 12 '17 at 11:16

vanlooverenkoen

2,121
26
50

score 0 · Answer 3 · answered May 10 '18 at 08:15

I had a similar seemingly perplexing problem, but the solution was simple. I was comparing a non-String object with a String therefore it failed. The confusion comes in because the description of non-String object looks like a String without the escape characters.

To solve the problem, I changed:

assertThat(message, is(expectedLog));

to:

assertThat(message.toString(), is(expectedLog));

Hamcrest matcher with slashes is interpreted as a part of validation

3 Answers3

Linked