RestAssured#3-Why automate Webservices/REST API?

RestAssured#3-Why automate Webservices/REST API?

Before diving into what and how to test REST API. In this article first, let's see why we should bother to test/automate REST API at all.

Traditionally most of the automation effort goes into writing automation scripts for UI. We know we should automate our tests, but we tend to avoid it because automated tests were considered expensive to write after a feature is added to an application. One reason why it was difficult to write tests sooner was that they were automating at the wrong level.

The Test Automation Pyramid This term is first coined by Mike Cohn in the book "Succeeding with Agile".

image.png

Source - martinfowler.com/articles/practical-test-py..

At the base of the pyramid is unit testing. Unit testing should be the foundation of a solid test automation strategy and as such represents the largest part of the pyramid. They are extremely quick and very precise. And when things break, they tell us exactly where things went wrong.

At the top of the pyramid is the user interface level. Automated user interface testing is placed at the top of the test automation pyramid because we want to do as little as possible, because of the following negative attributes:

  1. Brittle - A small change in the user interface can break many tests. When this is repeated many times over the course of a project, teams simply give up and stop creating tests every time the user interface changes.
  2. Expensive to write - A quick capture-and-playback approach to recording user interface tests can work, but tests recorded in this way are usually the most brittle. Writing a good user interface test that will remain useful and valid takes time.
  3. Time Consuming - Tests run through the user interface often take a long time to run.

Testing through the user interface is expensive and should be minimized.

The middle layer i.e. integration/service layer doesn't go through the UI. They start one layer down and test the underlying services. This gives them the advantage of not having to deal with the fragility of the UI, while still retaining some of the ability to check that things are properly hooked up and connected. At this layer, we test Web services and APIs.

Rules of Thumb

  1. When adding a new test, always see if you can cover it with a unit test first.
  2. Always push tests as far down the pyramid as you can.
  3. Don’t try to automate everything. Instead, automate just enough. As wonderful as automated tests are, every test has a price in terms of cost and maintenance. So we don’t want to automate everything. Instead, we want to automate just enough. Easy to say—hard to do.

img-2.png

Source - Book - The Way of the Web Tester

Did you find this article valuable?

Support SUBODH SINGH by becoming a sponsor. Any amount is appreciated!