Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What is the best way to test REST services in Java? What approaches and tool set do developers usually take?
Also if you are writing rest clients that call into third party REST services. What is the best way to test REST clients. Do you have JUnit tests that communicate with a third party REST service. You could run into the risk of service not being available/or production REST service cannot be access without certain credentials.
I suggest that you take a look at REST Assured for automated testing of REST services. The following example is copied from it's web page:
For example if your HTTP server returns the following JSON at “http://localhost:8080/lotto/{id}”:
{
"lotto":{
"lottoId":5,
"winning-numbers":[2,45,34,23,7,5,3],
"winners":[
{
"winnerId":23,
"numbers":[2,45,34,23,3,5]
},
{
"winnerId":54,
"numbers":[52,3,12,11,18,22]
}
]
}
}
You can easily use REST Assured to validate interesting things from response:
#Test public void
lotto_resource_returns_200_with_expected_id_and_winners() {
when().
get("/lotto/{id}", 5).
then().
statusCode(200).
body("lotto.lottoId", equalTo(5),
"lotto.winners.winnerId", containsOnly(23, 54));
}
See the getting started and usage guides for more information.
If you have implemented your server app using Spring Boot, you may also find the blog post about Integrating Testing a Spring Boot Application that I wrote a couple of years ago interesting. It shows how Spring Boot test support starts an embedded web server and deploys the application to it before executing REST Assured based tests against the REST API. In other words, neither do you have to manually start a web server, nor do you need to re-deploy the app between tests. As a matter of fact, you do not even have to create a .war or .jar file between your code changes in order to validate REST API changes.
1. What is the best way to test REST services in Java? What approaches and tool set do developers usually take?
You can test your rest services by first testing the actual code and functionality of the service itself and make sure it is functioning properly using any unit testing library applicable to your project.
Next, you would publish the REST service and try accessing the RESTful methods using a http client of some sort.
Generally, the easiest way is just a plain old browser. Type in the url and information if it is a GET or PUT based request. If it is a post, you can use browser plugins or dev tools to help add data to the body of the request or header as needed and validate you are getting the response you expect. If it works in a browser, it should perform similarly with any HTTP capable client you choose.
2. Also if you are writing rest clients that call into third party REST services. What is the best way to test REST clients. Do you have JUnit tests that communicate with a third party REST service. You could run into the risk of service not being available/or production REST service cannot be access without certain credentials.
You can generally use any sort of Http Client library you wish based on the language you are using. The main pitfall to look out for with testing of a REST client is to make sure you are capturing the Response returned by the REST service and checking the status. If it is good, you will get a 200, server error 500, etc. etc.
I recommend taking a look at W3C or Wikipedia status code information https://en.wikipedia.org/wiki/List_of_HTTP_status_codes or https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.
Further, you should understand the types of responses that are possible to be returned from the particular service. This should be available in the api documentation for the service. The api should also explain any sort of credentials or requirements that need to be passed through the header or as a parameter to the REST call.
Understanding how REST works and HTTP in general would be good starting points.
There are several ways to test REST API, depends on your needs:
Jersey Test - you can execute and test REST API calls with in-memory HTTP server. You'll need to mock your code - use Mockito (Jersey 1.19 Test configuration - mock classes) or in-memory testing database.
Rest Assured - the main drawback is that you need to run REST API project separately/individually from tests (RestAssured testing without running Tomcat)
Tools with UI - SOAP UI or Postman
Swagger - generates interactive documentation - web page where you execute REST methods with prepared data according annotated methods in a code.
Use Spring Boot for developing REST services. It has various tools for testing which you can use out of the box without excessive configuration.
You can create a REST Service mock using SoapUI. Also, if you needed to run this test through maven, you can use soapui-maven-plugin to instanciate do soapui service automatically
For part 2 in your question, the correct answer depends on various factors. You would want to consider both the resolution of the mocking and the time spent writing and maintaining the tests.
Client library
The choice of HTTP-client will affect your options - some klients (like Spring RestTemplate) offer built-in mocking support. If you have a service definition like a swagger or RAML file, you'd want to generate the client.
Project configuration
The most thorough way is to actually let the application make HTTP calls to real endpoints, involving the full stack. If so, configure your project so that the client URLs are injected in a per-environment (or profile) fashion.
Mock endpoints
You want mocking per unit test. No 'deployable mocks' which serve multiple unit-tests. Services are mocked on a localhost port - preferably randomly selected so that parallell testing is possible (i.e. on jenkins).
Mock data
To save time, for deep data structures, it is very desirable that mock data is read from a file, rather than constructed programmatically. Files are much easier to work with, especially if you enable request/response logging, fixing bugs and so is faster.
Mocking
Some frameworks are loosely coupled to the service, as in they are strictly not aware of the nature of the service. Typically you'd mock a respons at some path which is coded in the unit test. This is like Wiremock and most of the test frameworks I've seen.
Whereas other tools work directly on class service definitions, basically you'd use a tool like Mockito to mock an object directly (but wrapped in a real endpoint). This should be less error prone, but requires the classes to be present (as test dependencies). I've written a tool like that, for comparison.
Related
I am exploring Karate API double (mocking) for the integration test. For the below scenarios, I'm not getting the expected mocking response. Your help will be appreciated.
My Setup :
1. Karate Mock Server up with pathMatches rules on port 8001: http://localhost:8001 ( working, validated against "/cat" and some test calls)
2. My own Application is up from docker on port 8080. From Docker exposed 8001 port as well.
Mocking Case:
1. My application REST call exposed to all users http://localhost:8080/service/v1/findUser. This exposed API, underlying calling other REST call http://dev-STG/userservice/v1/findUser which actually giving JSON response. So, I want to mock underlying API call and validate my API behavior accordingly.
Steps tried:
1. Now, in my application config, m replacing actual underlying API call to Karate mock server(http://localhost:8001/userservice/v1/findUser). Then did build & up my application docker.
In Karate, I defined test e.g "testIntgrtn.feature" which calling my application API "http://localhost:8080/service/v1/findUser" and Karate mock server up and set with pathmatch "/userservice/v1/findUser".
After executing "testIntgrtn.feature" karate not mocking for an underlying call(http://localhost:8001/userservice/v1/findUser).
Now, in "testIntgrtn.feature" file I changed my-application URL to underlying REST URL i.e (http://localhost:8001/userservice/v1/findUser) then mocking will work like charm.
I'm not understanding why underlying API call not getting mocked here? Did I miss something here?
Also, in Karate can we monitor all REST calls (like cypress mocking).
Thanks for this wonderful framework. Which is intuitive for writing automation cases.
Karate cannot automatically intercept calls.
The recommended approach is when you boot the application running at localhost:8080 you change the configuration so that instead of calling http://dev-stg/userservice/v1/findUser it calls something like http://localhost:8001/v1/findUser. This is what most teams do, and is easy because you should anyway be defining external URL-s as application.properties (or equivalent) as a best-practice.
It is very easy to over-ride an application property in Spring Boot for example, you can do this via the command-line: https://stackoverflow.com/a/37053004/143475
If you want, you can dynamically provision a port for the mock. So your unit test can first start a mock, get the port, and then start the server. You can find details in the Karate documentation.
All this said, if you are able to change the (system) HTTP proxy before the app at localhost:8080 starts, you may be able to do this without modifying the configuration. (But it is tricky, so I recommend the approach explained above.) So in this case, Karate can actually "intercept" the outgoing HTTP calls that the app at localhost:8080 makes.
See the second-last row (5a) in the table here: https://github.com/intuit/karate/tree/master/karate-netty#consumer-provider-example
I am trying to write code to invoke external services using java Httpurlconnection and noticed code is getting duplicated , but I am confused now whether to duplicate code or use lots of if-else block and write everything in single place.
Following are scenarios or type of services needs to be invoked -
1. Post/put/get Rest service with basic authentication over http protocol
2. Post/put/get Rest service with basic authentication over Https protocol
3. Post/put/get services with different oauth authentication options, here one more call to get token is required.
4. Soap services with different authentication method.
The response processing logic also differs for different type of services.
As of now I have written separate methods for each of these, but this is not reusable as it's tightly coupled with type of service.
Can anyone suggests better design approach for this?
You can abstract iteraction with API into separate service or services. For example TaskApi with getTasks(), sendTask(Task task), etc. methods. Look at Retrofit library, it much more convenient than using HttpURLConnection and helps you to solve authentication issues easy.
I am presently working on an application which has an external dependency on micro-services, there are around 25 microservices, which are administrated via a eureka instance, every microservice has around 3-4 controllers.
This is an external dependency for me and blocks my work if it goes down, also I am unaware of the code ad logics for these microservices.
Currently, I am looking for a solution which can act as a simulator for these services in there absence, some application which can intercept and log, all the request and response to/from the external services, and in absence of these services it can match the last response to a requests from log and provide that response.
you should check mockito or any other mock framework
just record and serialize the result e.g. with xstream and respond with the deserialized xstream result and modify it slightly by your needs.
This is the quickest solution for mocking remote services.
I am using TestNG to write test cases.
I want to write a test case for my Rest API, and my server is not up. It means no one is giving me a response.
I have URL which I can hit. I know the response also what should come as a response when I hit the URL.
It is possible using directly hit the API, fetch the response and then from the response fetch the body and check it whether it is true or not?
I don't want that way means my server is not.
Is this any way to mock the Rest Service and implement that?
There are numerous ways how to approach your issue. Whether they would be easy or complicated depends on what was the way your service under test was implemented.
You can configure the required mock using Soap UI for example or WireMock. Unlike the previous ways you can build your mocks automatically if the developers used frameworks like Swagger (Swagger mock server) to describe the REST service.
Here are some tools that I have found to test web services consumers:
http://www.soapui.org/
https://wsunit.dev.java.net/
Are there any others? I would prefer testing frameworks that are written in Java or Python.
I have used soapui by a maven plugin. It can create junit-linke reports to be run and analysed like unit tests. This can be easily integrated in continious build, also with the free distribution of soapui.
I've used Web Service Studio.
Web Service Studio is a tool to invoke web methods interactively. The
user can provide a WSDL endpoint. On clicking button Get the tool
fetches the WSDL, generates .NET proxy from the WSDL and displays the
list of methods available. The user can choose any method and provide
the required input parameters. On clicking Invoke the SOAP request is
sent to the server and the response is parsed to display the return
value.
This tool is meant for web service implementers to test their web
services without having to write the client code. This could also be
used to access other web services whose WSDL endpoint is known.
Also the Web Services Explorer in Eclipse which comes as part of the Web Tools Platform.
Through UDDI and WSIL, other applications can discover WSDL documents
and bind with them to execute transactions or perform other business
processes. The Web Services Explorer allows you to explore, import,
and test WSDL documents.
The Grinder is right up your ally with both Java and Python, that handles most web services, (SOAP/REST/CORBA/RMI/JMS/EJB) etc.
http://grinder.sourceforge.net/
You really need to be more specific: What is it that you want to test in your WS-consumer? That it calls the right WS? This looks a bit pointless - WS are a perfect place for mocking whatever may be called - without anything being called.
In order to test the consumer you'd otherwise be writing a Webservice that mocks the original, right? I'd suppose that the communication protocol that goes through the wire is not the clients domain - e.g. it's generated. So the only thing a WS-consumer's client sees is the interface. And there's nothing to test in an interface.
It might be that I completely misunderstood your question - please clarify if I did. I'll revise the answer then.