This question already has an answer here:
Karate API Testing - Reusing variables in different scenarios in the same feature file
(1 answer)
Closed 1 year ago.
I have a requirement to pass the response of first web services to next service. We maintain one scenario for each web services. Some of the tags in first services needs to be passed to next web services within the feature file itself. Please help.
Thanks,
Thiyagu
I think you have fundamentally misunderstood the way a Scenario works. Each Scenario is supposed to be independent. You can't have one Scenario update a variable and then expect that other ones can see the updated value. Please combine your 'flows' into one Scenario. Or if some 'setup' steps are common, use a Background section.
Keep in mind that you should be able to comment-out a Scenario or skip some via tags without impacting any others.
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
I need to post a request to get an authorization token and include it in the header for all subsequent test requests. This token changes every time but it is valid for the entire test session as long as I keep sending requests. In each feature file I can call another feature file to get this token. But I don't want to do this for every feature file. I just want to get the token one time at the start of the test and use it for all feature files. How do I do that? I've read the Karate information on GitHub but did not find the answer.
The second example in the demos answers all your questions: karate-demo.
EDIT1: Sorry, I read your question too fast. You can use karate.call() in karate-config.js so it applies to all feature files. I don’t recommend this because you will always have some features where you DONT need this. Just use a call to a feature and don’t over-engineer your tests.
EDIT2: I thought about this a little more, if you are comfortable with Java, you could make a call to a singleton at the start of each feature (or even in the global karate-config.js) and in that singleton cache the value of the auth token. So you can do exactly what you need and it will be flexible.
EDIT3: based on this question - we added this functionality to Karate as a karate.callSingle() operation, here's the doc: https://github.com/intuit/karate/tree/develop#the-karate-object
This question already has answers here:
Supporting multiple languages in a REST API
(3 answers)
Localization for REST APIs
(2 answers)
localisation in RESTful services
(1 answer)
RESTful URL: where should I put locale? example.com/en/page vs example.com/page?locale=en
(2 answers)
Closed 2 years ago.
I need to come up with best practices for API development where we have more than 100 endpoints to be developed and each endpoint need to have below mentioned properties which are common to be passed as request to the server
Every request must have language-code (en-us or en-ca), division (hr or finance) and country (US or CANADA) parameters
Two versions of apis needs to be created for web(v1) & ipad(v2)
Would like to know what is the best way to frame the api urls by taking above 2 points into considerations
I am planing to do the versioning mentioned below, but confused how to incorporate the above mentioned 2 points in the request (request params or through headers or in the request body itself)
app/v1/api/url
app/v2/api/url
I think there are a lot of good resources about REST API design e.g. 1 2. You should read them.
So I would use a query parameter for your language, division and country. These are like meta data shared across most of your apis.
app/v1/api/url?lang=en&div=hr&country=es
Regarding your second point I am not sure if you should distinct between the different device types. But it might be necessary. If so start with your device type. Because it might help you with your permission framework.
app/v1/api/url
web/v1/api/url
or
app/api/v1/url
web/api/v1/url
Hope this helps a bit.
Update 1
I like #Evert idea to use the Accept-Language, I think it is better as it is a standard http header field.
I still have issues in my project to fully automatize a survey creation process.
Thanks to this post, I managed to get additional question properties.
But now, I would like to set additional properties.
I tried the same syntax, just replacing aQuestionSettings param in get_question_properties with aQuestionData in set_question_properties.
Is it possible do this with Limesurvey API ?
I have few questions for you. Let me give some details before I throw the questions.
Recently I have been involved in Rest api test automation.
We have a single rest api to fetch resources,( this api is basically used in our web app UI for different business workflows to get data)
though its the same resource api, the actual endpoint varies accordingly for different situations
.i.e the query parameters passed in the api url gets differed based on the business workflow.
For example something like
`./getListOfUsers?criteria=agedLessThanTen
../getListOfUsers?criteria=agedBetweenTenAndTwenty
../getListOfUsers?criteria=agedBetweenTwentyAndThirty etc
As there is only one api and as the business workflow do not demand it, we don't have chaining requests between apis
So the test is just hitting on individual endpoints and validating the response content.
The response are validated based on a supplied test data. So the test data file has list of users expecting when hit on each particular endpoint.
i.e the test file is like a static content which will be used to check the response content everytime we hit on it...
if the actual response retreived from server deviating with our supplied testdata,it will be a fialure.
(also tests are there for no content respose,with out auth etc)
This test is ok to confirm the endpoints are working and response content is good or not .
My actual questions are on the test strategy or business covergae here,
Is such single hit on the api end point is sufficient here or not..
or same endpoint should be hit again for other scenarios or not, especially when the above given example of endpoints actually complimenting each other
and a regression issues that might happen, can possible captured in anyof it ?
If api endpoints are complimenting each other, adding more tests , will it be just duplicate of tests/ more maintainance / and other problems later on and should we avoid it ?
if its not giving values ?
Whats the general trend on API automation regarding the covergae? . I beleive it should be utilzed to test the business integration flows, and scenarios if it demands
but for situations like this , is it really required
also should we keep this point in mind here ?, that automation is not to replace manual testing, but only to compliment it .
and attempt to automate every possible scenario is not going to give value and only will give maintaince trouble later ?
Thanks
Is such single hit on the api end point is sufficient here or not..
Probably not, for each one you would want to verify various edge cases (e.g. lowest and highest vales, longest string), negative tests (e.g. negative numbers where only positive allowed) and other tests according to the business and implementation logic.
Whats the general trend on API automation regarding the covergae?
...
automation is not to replace manual testing, but only to compliment it . and attempt to automate every possible scenario is not going to give value and only will give maintaince trouble later ?
If you build your test in a modular way then maintenance becomes less of an issue, you need to implement each API anyway and the logic and test data above that should be the less complicated part of the test system.
Indeed you usually want to have a test pyramid of many unit tests, some integration tests and fewer end to end tests, but in this case since there is no UI involved, the end user is just another software module, and execution time for REST APIs is relatively short and stability is relatively good then it is probably acceptable to have a wider end to end test layer.
I used a lot of conditionals above since it's only you that can evaluate the situation in light of the real system.
If possible consider generating test data on the fly instead of using hard coded values from a file, this will require a parallel logic implemented in your tests but will make maintenance and coverage an easier job.