Developers while building the application do not go through the whole control flow every time they test what they just coded. Instead the back-end developers working on the server side just test the API level messages being received and sent. Similarly, the front-end developers working on the client side (front end scripting) would also test their piece of code by simulating API messages. This makes testing both areas (front end and back end) less complex and quick.<\/p>\n

What\u2019s in all of this for the automation guy? We can break down a complex application\u2019s automation into smaller and easier solutions. For applications which are huge, specially having a lot of business logic, it would be a nightmare to have decent code coverage from the UI level. API calls would make that job so much easier and effective.<\/p>\n

Complex UI<\/h2>\n

Sometimes we run into problems on the UI level where certain elements on the web page are not recognized easily by the tool, or do not always perform the way it\u2019s expected by the tool. These tests generally termed as \u2018not automatable\u2019 can be covered from API level tests since we don\u2019t have to deal with the user interface level complexities.<\/p>\n

Service virtualization<\/h2>\n

Many areas of the code need a very specific circumstance to execute which is sometimes very difficult from UI tests. Perhaps there are third party APIs involved, or some external hardware sending in data used by our application, or a piece of code which is scheduled for development in the future needs to be simulated for other teams to complete their feature set. We had a similar problem in one automation project where the server was supposed to receive input data from a hardware device which was still under development.<\/p>\n

On the API level this becomes way lot easier. Mostly in such cases the input \/ output of the API is defined. Lots of tools are out there which can simulate the required calls or responses. It\u2019s then just a matter of constructing the calls properly and validating the expected responses. You might need to create a test harness using other tools \/ frameworks, but it\u2019s a very powerful concept.<\/p>\n

Input for UI tests<\/h2>\n

Creating pre-test data and \/ or removing it at the end of the test can becomes a problem. API level tests can be very effective for test data management. Again one or more structured API requests would do the trick in no time. Similarly, for deleting data which is no longer needed should be equally simple (except where business logic is complex enough blocking the removal of a record by simply one call).<\/p>\n

Would love to hear what other uses you can think of API tests.<\/p>\n<\/div>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":13333,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[44],"tags":[],"yoast_head":"\n