Data-driven API testing framework, where you can define your APIs and scenarios and execute it without much code. A open source tool from http://techconative.com/
At the moment we will not be able to pass parameters for individual test apis and the parameters are available only at the level of test scenarios.
This has a limitation when we have to reuse a single api definition with different parameters under a given scenario. For ex, when testing a delete user scenario, get_user has to expect 200 response code before deletion and 404 after deletion of the user. For this scenario, currently the user has to define 2 different test_api entries one for status code 200 and another for 404, with almost all other the definitions stays the same. This will result in too much of duplicates in the
To enhance the support, there were a couple of discussion that happened and we planned to go ahead with the below approach,
- Create a new sheet(scenario_test_mapping).- This sheet will contain the following columns,- scenario_name- test_api- test_api_param- The existing test_apis column in Test_scenarios will continue to exists for simple use cases and the users will use the mapping only if they have to control params at individual test level.- If a scenario contains tests in both Test_Scenarios and scenario_test_mapping, the one in scenario_test_mapping takes precedence.
Create a sheet test_api_wrapper.
Test api wrappers are like decorators for test apis, where it just provides parameters required for test api, but uses the underlying test api for all other definitions.
The entries in test_api_wrapper contains name, description ,test_api and params.
The test_api field in test_scenario can either refer to test_api_wrapper or test_api interchangably.
The rationale has to be reflected in the sheet structure.
Support params to individual test cases
At the moment we will not be able to pass parameters for individual test apis and the parameters are available only at the level of test scenarios.
This has a limitation when we have to reuse a single api definition with different parameters under a given scenario. For ex, when testing a delete user scenario,
get_user
has to expect 200 response code before deletion and 404 after deletion of the user. For this scenario, currently the user has to define 2 differenttest_api
entries one for status code 200 and another for 404, with almost all other the definitions stays the same. This will result in too much of duplicates in theTo enhance the support, there were a couple of discussion that happened and we planned to go ahead with the below approach,
- Create a new sheet(scenario_test_mapping
).- This sheet will contain the following columns,- scenario_name- test_api- test_api_param- The existingtest_apis
column inTest_scenarios
will continue to exists for simple use cases and the users will use the mapping only if they have to control params at individual test level.- If a scenario contains tests in bothTest_Scenarios
andscenario_test_mapping
, the one inscenario_test_mapping
takes precedence.test_api_wrapper
.test_api_wrapper
contains name, description ,test_api and params.test_api
field intest_scenario
can either refer to test_api_wrapper or test_api interchangably.