4

A few thoughts: Automation code should be reviewed, so I don't think that's a con Not sure why failing test cases would keep your build from compiling. Even if the test code lives in the same repo as the application code, your build scripts should ignore the test code when compiling deliverable code. There might be a failure further down your build chain ...


3

As with any project, it depends :). That said, (1) and (2) require close coordination with development team. Depending on the team structure it may be a good thing or a bad thing :). I also suspect in both cases some code will have same development (unit) tests as your tests. For example, a DTO might have a bug which may not be caught by both the teams. (3) ...


2

Here's a number of design patterns you can use for testing REST services (with REST-assured, but not necessarily*): Service Object pattern. Just like Page Object encapsulates HTML page, Service Object encapsulates REST API. Hence, instead of dealing directly with forming HTTP requests and parsing HTTP responses, you can use business level methods like ...


2

Now take a look at setFormParam() method: System.out.println(reqSpec);// reqSpec Always getting null value reqSpec.formParam(keyValue[0], keyValue[1]); and then at postCandidateResponse() that calls setFormParam(): public static Response postCandidateResponse(Hashtable<String, String> data) { requestSpec= TestUtils.setFormParam(data.get("...


2

What you show is actually a response body. Headers are represented in "Headers" tab in Dev Tools like this: Brief look up of what you provided shows that it's UTF-16 encoded string: For example: 1 - BATAK LETTER CA 2 - MANDAIC LETTER ATT 3 - http://www.fileformat.info/info/unicode/char/41bc/browsertest.htm no dedicated name


1

Is it a fair test? Not really. Performance tests usually involve warm-up phase as anonygoose suggested in his/her answer. For instance, in case of HTTP clients this is to let them start thread and HTTP connection pools. Performance tests should sent many requests over time. If you're sending only one request you might be simply out of lack as the server ...


1

According to this question Rest Assured is pretty slow on the first request you make. Looks like it has to warm up a little for some reason. I've tested version 4.0 of Rest Assured myself, and this appears to be the case. The first request is 2000ms+, then every subsequent request in the same suite is 200-300ms. A counter question might be: why compare ...


1

You can convert the JSON string into a JSON Object and then use <your_field>.remove() and get the updated JSON back by converting it back to string. Below is a small example which demonstrates this: import org.json.JSONException; import org.json.JSONObject; import java.util.ArrayList; class Scratch { public static void main(String[] args) ...


1

It depends on the service. If I'm testing something that doesn't change, or doesn't change often, I would assert the response against a benchmark response. For those services where the data may change, I would look to write some sort of validation script to compare the response results with the db.


Only top voted, non community-wiki answers of a minimum length are eligible