# Automation Test Framework for Automatic API and Java-SDK Testing
## Automatic API Testing
Depend on Open API technology, This test framework helps you to verify the correctness and compliance of micro-service's exposure APIs.
Especially, it gives great supports in regression tests.
# Automation Test Framework for REST-ful API and Java-SDK Testing
## REST-ful API Testing
Supported by Open API technology, This test framework helps you to verify the correctness and compliance of micro-service's exposure APIs.
Especially, it gives great supports and decreases too much efforts in regression tests .
Assumed we have a simple software product and it has following business call flow:
```FrontEnd_Svc ---- <RESTful Req1> ---- BackEnd_Svc1 ---- <RESTful Req2 which triggered by RESTful Req1> ---- BackEnd_Svc2```
If we have the predefined RESTful API of BackEnd_Svc1 & BackEnd_Svc2, then much repetitive end-to-end verification efforts can be saved.
If we have the predefined REST-ful API of BackEnd_Svc1 & BackEnd_Svc2, then much repetitive end-to-end verification efforts can be saved.
Automation API test consists following 2 parts:
1. Verify the exposed APIs work as design in BackEnd_Svc1 and BackEnd_Svc2
* To have this test framework generated RESTful requests automatically based on API definition.
* To have this test framework generated REST-ful requests automatically based on API definition.
Note:
- For easy to use and test efficiency, except user and organization info, no need to persist more testing data.
- So in the expectation of automation test, GET/PUT method request with a specific ID (it is the maximum value based on the data type) will be failed perhaps, but most of POST method requests should succeed.
- For those optional query parameters in path, requests will be sent out twice. One is with them, another is without them.
- Each field in Json body of request will use the boundary values based on data type.
* After received the response, it will check HTTP status code and json_body with above API definition also.
* Ont only verify the positive call flows, it can generate some negative test cases automatically depend on "parameters" type (e.g. over the boundary).
2. Similarly, we can construct some HTTP servers as mocks when the BackEnd_Svcs are still in developing.
With it, we can verify business logic of FrontEnd_Svc OR triggered behaviour in BackEnd_Svc1, not to care about development progress of Back1End_Svc1 OR BackEnd_Svc2.
\ No newline at end of file
* With it, we can verify business logic of FrontEnd_Svc OR triggered behaviour in BackEnd_Svc1, not to care about development progress of Back1End_Svc1 OR BackEnd_Svc2.
3. Limitation
* All automatically generated requests does not consider business logic. So the assert failure is not real failure, manually double check is preferred.