I have different test suites created in SOAP and i want to add common assertions to test suites level so that i can change/update it easily.
Any solution on this..? Please help
Related
I am quite new to JGiven and currently I have a set of REST API tests automated using Rest Assured and TestNG framework. I am also exploring JGiven as a framework to run the API tests for the advantages it gives with the human readable given when thens and the reports that it generates too. Rest Assured as a library lets us inject the URLs and actually make the REST calls. I want to understand if we have such capabilities within JGiven to actually make the REST calls. If so, I'd like to see an example and understand how I can do that. If not, can someone kindly advice and suggest the best way to achieve it with JGiven. I've been trying to search for this information but have struggled to do so thus far.
Thanks in advance.
JGiven is useful for creating test scenarios that are understandable by domain experts. It is a general tool that can be used for any kind of testing, including testing REST APIs. JGiven adds an understandable layer on top of your underlying test infrastructure. However, you will typically need tools in addition to JGiven to implement the underlying layer. So for testing REST APIs you will use a tool like Rest Assured in combination with JGiven. With JGiven you describe your scenario in the domain language, with Rest Assured you will execute the REST calls.
I need to write a junit test case for REST API.Am new to Junit test case can anyone help me to understand and write the test cases for REST APIs with so many EJB injections.
Do i need to call the actual api end point while writing the test cases or can i mock a server to achieve the junit test cases for APIs.
junit test cases must display the code coverage, how can we achieve this.
Note: REST Application is NOT a spring based application.
I know what Rest Assured is and for what purpose it is used and the same for the cucumber.
But the thing is what we can achieve with Rest Assured, we can also do with Cucumber for testing.
Rest Assured simply calls the web service and validates the response. We can't use Rest Assured during the Maven build because the service needs to be up and running.
But with Cucumber I can directly call the web service's business service layer and DOA layer and validate the response. Cucumber can invoke this at Maven build time.
So question is which one is better? I know we can use/integrate Cucumber with Rest Assured but.
Cucumber is a BDD tool and can be used to describe the expected behavior and use those descriptions as the basis for test automation.
RestAsured is a tool to test API's/http calls.
They do something different.
You could use them both: Cucumber to describe you functionality, and RestAssured to do http calls.
But with Cucumber i can directly call the web service's business service layer and doa layer and validate the response.
This is not necessarily true, and it has to do with the test level you want to achieve.
So if you just want to do tests on a unit level, then yes, you don't need to use REST assured, you can perfectly specify your tests with Cucumber feature files, and in the step definitions, you can test the service layer and the DOA layer directly, like you mentioned.
If you want to test a running instance of the webservice then you can use REST Assured or REST Assured plus Cucumber. REST Assured will only help you simplify the actual definition of each part of the test and the interactions with endpoints and its expectations, and Cucumber will allow you to define the high-level scenarios made of those steps.
So the question is which one is better? I knew we can use integrate cucumber with rest assured but.
All in all, it's not a matter of which one is better, but what level of testing you're trying to achieve and how you want to achieve it. A unit level you might not need REST assured. On an integration/live-execution level, then yes, you can use that library. In both levels, you can specify your tests using Cucumber.
Rest assured is java Api libraries to do automate REST web services. we can automated Rest apis by using BDD method,BDD is method and Cucumber is leading and free tool for that
Rest assured is not a tool it is a java library which we can use for test restful webservices, and yes cucumber is recommended to use because customer is giving better reporting which rest assured is not supporting to reports.
So I can recommend use cucumber framework to test API
I want to write a web application with a simple Frontend-Backend(REST API) architecture.
It's not clear to me where and how to write tests.
Frontend: should I write tests mocking API responses and testing only UX/UI?
Backend: should I write here API call testing and eventually more fine grained unit testing on classes?
But in this way I'm afraid that Frontend testing is not aware of real API response (because it's mocking independently from the backend).
On the other side if I don't mock API response and use real response from backend, how can the Frontend client prepare the DB to get the data he wants?
It seems to me that I need 3 kind of testing types:
- UX/UI testing: the Frontend is working with a set of mock responses
- API testing: the API is giving the correct answers given a set of data
- Integration testing: The Frontend is working by calling really the backend with a set of data (generated by who?).
There are framework or tools to make this as painless as possible?
It seems to me very complicated (if API spec changes I must rewrite a lot of tests)
any suggestion welcome
Well, you are basically right. There are 3 types of tests in this scenario: backend logic, frontend behaviour and integration. Let's split it:
Backend tests
You are testing mainly the business logic of the application. However, you must test the entire application stack: domain, application layer, infrastructure, presentation (API). These layers require both unit testing and integration testing, plus some pure black box testing from user's perspective. But this is a complex problem on this own. The full answer would be extremely long. If you are interested in some techniques regarding testing applications in general - please start another thread.
Frontend behaviour
Here you test if frontend app uses API the right way. You mock the backend layer and write mostly unit tests. Now, as you noticed - there can be some problems regarding real API contract. However, there are ways to mitigate that kind of problems. First, a link to one of these solutions: https://github.com/spring-cloud/spring-cloud-contract. Now, some explanation. The idea is simple: the API contract is driven by consumer. In your case, that would be the frontend app. Frontend team cooperate with backend team to create a sensible API, meeting all of client's needs. Frontend tests are therefore guaranteed to use the "real API". When client tests change - the contract changes, so the backend must refactor to new requirements.
As a side note - you don't really need to use any concrete framework. You can follow the same methodology if you apply some discipline to your team. Just remember - the consumer defines the contract first.
Integration tests
To make sure everything works, you need also some integration e2e testing. You set up a real test instance of your backend app. Then, you perform integration tests using the real server instead of fake mockup responses. However, you don't need (and should not) duplicate the same tests from other layers. You want to test if everything is integrated properly. Therefore, you don't test any real logic. You just choose some happy paths, maybe some failure scenarios and perform these tests from user's perspective. So, you assume nothing about the state of the backend app and simulate user interaction. Something like this: add new product, modify product, fetch updated product or check single authentication point. That kind of tests - not really testing any business logic, but only if real API test server communicates properly with frontend app.
Talking about the tools, it depends on your language preferences and/or how the app is being constructed.
For example, if your team feels comfortable with javascript, it could be interesting to use frameworks like Playwright or WebdriverIO (better if you plan to test mobile) for UI and integration tests. This frameworks can work together with others more specialised in API testing like PactumJS with the plus that can share some functions.
Organising the test correctly you will not have to do a big extra work if some API specs changes.
I'm currently developping a REST Web service with Spring MVC.
And I am struggling to find the best way to do integration tests on my WS.
First solution : using rest-assured
Advantage : fluent api, really easy to use with its cool DSL
Drawback : when i perform POST or PUT requests on my WS, the state of my database is modified, and next tests are corrupted.
Second solution : unit test the controllers and perform integration tests at the service level separately
Advantage : i can control the state of my database, using Spring Test Framework and perform rollback after each test
Disadvantage : i do not perform end-to-end integration tests anymore.
Question : how can i use rest-assured to do integration tests without modifying the state of my database ?
Thanks a lot.
Why don't you delete the rest assured doubles and redirects before every test and set them up fresh for the test?
RestClient.delete "#{RestAssured::Server.address}/redirects/all"
RestClient.delete "#{RestAssured::Server.address}/doubles/all"
Or alternatively you can use different doubles for the GET and POST/PUT calls to the rest assured and use the redirects in between these calls.
I am not sure, your request makes sense as you state it.
RestAssured is just a framework to support you with testing. You can also write unit tests, that do the equivalent of PUT and DELETE (basically the internal implementations), which then modify the database state.
Or you can only issue HEAD and GET requests with RestAssured and not modify the database state by this.
Both of the options will only test parts of the code path if you leave any updates out, so your issue is orthogonal to the selection of RestAssured or hand written unit tests.
Of course you can mock your backend away, but either the mocks are trivial and you don't gain any insight. Or they are complex and you will need separate tests to assure that the mock objects to what you think they are doing.
In order to perform integration tests on a REST Spring MVC Web Service, the SpringSource team has provided a new library called spring-test-mvc, which is now integrate to spring-test.
http://blog.springsource.org/2012/11/12/spring-framework-3-2-rc1-spring-mvc-test-framework/
For my special purpose, it is more adapted than Rest-Assured.