AUTHOR
Manju Sanjay
While products are getting developed incrementally, changes happen quickly and the code that worked yesterday can stop working today. You want automated tests that will find this as soon as possible. Automated tests are considered expensive to write and are often written after a long time after a feature had been programmed. The main reason that teams found it difficult to write
tests earlier are that they are automating at the wrong level.
An effective test automation strategy suggests automating the tests at three different levels.
- Unit testing should be the foundation of a solid test automation strategy. Since unit tests are usually written in the same language as the system, developers are usually comfortable writing them. If proper unit testing is done in early development, then it saves time and money in the end.
- Testing through the user interface can be expensive and should be minimized. Although many test cases need to be invoked, not all need to be run through the user interface, and this is where the service layer of the test automation comes in. All applications are made up of various services. A service is part of an application that has a business capability.
Let’s see the benefits of automating the tests of an application in the service layer.
Benefits of Service Level Automation
Business logic can be tested early
Take the example of an online freight booking application and see what the main business logic could be here. One might be that a user can come to the site and can login, which means basically the site provides the login service. It can be achieved by using their own gateways or maybe they can use a single sign-on or from a google account. More domain-specific actions could be to book a freight by providing the details like pickup and destination locations, request for a pickup, etc. Now think like you are writing automation for UI test cases by using Selenium or Appium you might have hundreds of test cases that might need to be executed which will take a lot of time to have the user access wait for the call, because it involves the backend API and also UI.
But when you only deal with the API testing, it gives you the quality of the core part, and assures the actual logic is working fine. Since it doesn’t involve the browsers, it smashes more on the business flow rather than the UI style or rendering issues. When the UI layer is ignored, it takes less time to execute an API and you can test the business logic fast. Most of the business logic are in the service layer. UI is the top layer for interaction between user and API gateways. If you want to test the business capabilities of your service, API should be the best option where an error-free business flow is guaranteed early.
Quality can be derived to use across multiple platforms
Once the API gets ready now there are client applications on the web as well as on mobile, that want to consume these a APIs. Since the business flows are automated and passed quality assurance, both clients can use these backend services
Reduce cost
Early-stage detection of issues can reduce the cost significantly. You may spend quite some time writing the UI test cases and then you will automate it. For example, execution of search functionality to list items coming under certain criteria which are selected by the user. Based on the wrong response from the API for the search service, the UI may be listing the incorrect
data. Here you have to wait till the development of the UI gets completed and the corresponding test cases are executed to find that the business logic was not correctly implemented in the service layer which may be very crucial then. More early you identify an issue, the less cost it carries.
Better test coverage
The service-level test automation requires less code since we don’t have to consider the browser-level constraints. Hence only less time will be consumed compared to automated functional testing making use of UI. Since all APIs can be tested separately the functionality test coverage can be more compared to the automated functional UI testing.
Helpful for performance test and security test
If the APIs are not tested, we cannot do the performance test or security test. In other words, one of the prerequisites for both these tests is that the backend gateway should be tested, and we should make sure that the APIs are working fine. Since the performance test is not to catch the logical bugs but to analyze the system behavior as a whole, make sure that the system is ready for the performance test, in the service layer. The same is the case with security testing where the purpose is to reveal any risk, vulnerability, or threat within the API. Doing the performance as well as security test of an incorrect business flow does not make sense
Conclusion
The problem that can cause when a service layer is not considered for automated testing is that all tests that are not part of the unit test end up being performed through the user interface. This results in tests that are highly expensive, very delicate, and have low test coverage. Service is something the application does in response to some set of inputs. Since all applications are made up of various services, the service layer mentioned is not restricted only to service-oriented architecture.