I have an application in which I need to do UI testing as well as rest Api testing.Could anyone suggest me any testing tool for this.
My framework will be data driven.
Also, it is 20% UI and 80% rest api testing.
It is good that you have decided 80% API tests and 20% UI tests, which will satisfy the test automation pyramid. Well, the test tools and frameworks completely depend on your language of choice.
For API tests
Java -- RestAssured
Python -- requests library
For UI tests, Selenium webdriver is my preferred choice.
If you are starting test automation, I would suggest start with reading the documentation.
Related
I'm using Nightwatch-Cucumber that based on Nightwatch.js. And I want to integrate REST API tests in my Nightwatch framework. Currently I only have End2End tests based on Selenium, but in future I want to have both test types in one framework to make it also possible to use the End2End tests and the REST API tests in harmony within one Cucumber test. So, I want to combine both tests.
What is the best and smartest way to implement such REST API tests in my test framework based on Nightwatch-Cucumber? I've tried some stuff with frisby.js, but this framework uses Jasmine and Jest and it's not a good idea to use it in combination with Nightwatch and Cucumber.
Any recommendations?
You can use request-promise.
In nearest future, new version of nightwatch-cucumber will work with Jasmine and Jest too.
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 am working on an application using Camunda BPMN. This application calls restful
services for fetching or saving or updating data in the backend. I want to write load performance tests for this application. I am able to test indivisual endpoints with scala scripts in gatling. But how to test one entire BPMN workflow ? Is there any headstart material that I can refer?
Load and performance testing is a very complicated topic and usually depends on number of external environment factors.
I think a good starting point would be a user guide and our examples repository to get general idea on testing practices.
Once you have chosen your way of testing the whole process you then would have to identify parameters that simulate high load in your environment and adjust them in your test.
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.
Can we use Selenium Webdriver or Watir WebDriver to automate Restful API?
Is there any tool that we can use to automate Restful API?
You could probably hack a horrible solution, but what you really want is rest-client:
https://github.com/rest-client/rest-client
It's designed for exactly the set of use cases that you're describing.
I've only used REST-Assured to populate test data for Selenium test which was very efficient.
Have a look at the API its simple to use and you can easily automate your Restful API alternatively SOAPUI will be your best bet.
https://code.google.com/p/rest-assured/
Not sure how one would use WebDriver for Restful API tests other than creating a UI that WebDriver would use. If that was the approach the tests would be much slower and more complicated than using rest-client.
We use rest-client, and prefer it over SoapUI because we also re-use the same code to set up and tear down Watir-WebDriver tests.
SoapUI works too and will likely deliver tests faster, but there is a lot of value in using rest-client to also keep the UI tests fast and reliable.
When considering load and performance tests, we are considering flood.io, SoapUI/LoadUI, and SOASTA. If we go with flood.io, we would still be using rest-client and re-using the same code for that as well.