Recent Blogs

Service oriented architectures (SOA) on Automation testing

How to use Apache Bench for Load and Performance Testing?

“Service-Oriented architectures on automation testing”. Before going forward let’s see what is SOA

What is Service oriented architectures(SOA)?

Service-Oriented Architecture (SOA) is a software design that comprises of software components providing service to meet the requirements of business processes and needs of software users.

Many types of tests, such as unit and integration testing, are already very well known and used. But as the architecture changes evolve, testing techniques need to evolve together.

Before our problem was simple, we had a system, base on the session. We could test our components individually, others connecting directly to the bank, and to the interfaces, we had a quality team.

Nowadays it is very common to work base on service architectures that applications consume. In this architectural model, we usually have a Back For Front(BFF) layer responsible for orchestrating several other servers.

Which is consumed by applications, whether mobile or web. Behind it, we have several services that in addition to responding to the BFF layer also communicate with each other.

When we get to that level of architecture, here comes the question “What now? How are we going to test this?” Often, due to lack of time, pressure, and lack of knowledge.

We end up doing what we already know, which is safer for us and we do only the unit tests and integration of the service we are developing, we rarely stop to test the whole.

Why should we test the whole?-SOA

The answer to that is simple. Suppose you have changed some business rules or some interface. When you go up and run the tests, they’re going to pass. But what about the other services? Do they know about this change? Have they been changed, too? Are you waiting for these answers?

You will hardly have that answer, unless, of course, your company is small and has only your team.

As the business grows and teams grow, communication difficulty increases and not everyone involve are aware of the changes.

The idea of testing the whole is exactly to ensure that no broken code will go up to production affecting too many services or even the application itself. We’ll know about the problem before it happens, and the teams involved can change it.

The following are the types of tests that we can automate to ensure quality over time.

Types of tests

There are several types of testing, each has its purpose and scope and must be used together. One complements the other.



Test a small piece of code, isolated from external components such as a REST service or a database. 

Example: Whether the payment discount calculation is correct.

Details and best practices

Unit tests aim to test the smallest piece of code possible, be it a business rule or the behavior of a component. Best practices suggest using TDD, a practice where you write code with the test in mind, for the better code design. Very hard-to-test code needs to refactor to smaller parts.


Clean code, easy to maintain, with low coupling and high cohesion. We also guarantee that business rules will continue to apply over time. This type of test is the fastest to run.

Difficulties and Disadvantages

By using many Mocks and simulations, it is far from reality and is not able to identify all possible errors. For this purpose, we have the Integration Tests.



To test the integration of the system to an external system as a database or a REST API for example. 

Example: Test whether the system is correctly persisting the data in the database.

Details and best practices

Integration tests are a complement to unit tests to test integrations. He gets closer to reality by using fewer Mocks. It can catch errors that unit testing would not catch, such as a wrongly written SQL statement, or some invalid value for example.


The advantages of these tests are in catching communication errors that would happen in production if the test did not exist.

Difficulties and Disadvantages

They are slower and more difficult to configure because they depend on external systems. They must be written on a smaller scale than unitaries.

Risk or safety


Simulate various types of attacks that the API may suffer. 

Example: SQL Injection, Command Injection, XSS, and brute force, among others.

Details and best practices

These are tests designed to ensure that we are protected from various types of attacks that we may suffer and potential vulnerabilities that exist to avoid them.


Ensures the security of your greatest asset, your data, and your customers’ data.

The lack of these tests can lead to data loss, company failure, loss of credibility, drop in market value, numerous processes, and can lead to arrest.

Difficulties and Disadvantages

To create these tests you need to think like a hacker and most people don’t have the time or expertise to think of all the ways your API can be attacked.



Validate the final behavior, that is, whether system outputs are working as expected. It can be about HTML pages or endpoints of a REST API. 

Example: Simulate the process of creating a user, listing, deleting, and ensuring that they are no longer there.

Details and best practices

In this type of test, we validate business rules and complete flows. To make it clear what the test is testing, both for developers and non-developers, we can use the BDD technique.

These tests are good to be written with a test professional and a business professional, so we don’t forget any validation. It also serves as documentation.


They can be written before the development is complete. These tests simulate users’ calls, and the tests are closer to reality.

Difficulties and Disadvantages

Functional tests need the real system, accessing banks and real systems. It traverses the entire flow, this makes the test slower and with more dependencies.



Ensures that a recent change will not cause bugs or break some old functionality. 

Example: Ensure that the change in the credit analysis rule will not break any functionality in the statement, in a customer’s offerings, or in the products that the customer already owns.

Details and best practices

This test is typically used after large changes are entered because it is a slow test. It goes through features already tested to ensure that there have been no new errors.

Unlike other tests, it will not check only one service, it will see the whole, will ensure that a change has not affected the rest of the system, such as changing a date or number format.


We guarantee quality over time as software evolves and that new functionality won’t break an old one. This type of testing will ensure that changing an interface in the REST API will not break the App for example.

Difficulties and Disadvantages

Regression tests are expensive and time-consuming. A good solution is to test only the features that can be impacted by that change.

Load or Stress


Service oriented architectures (SOA) on automation testing seek to test our software on extreme conditions of use in a short period, to verify response time and scalability. 

Example: Simulate the traffic of a Black Friday day before to see if the system will support the day and measure how much it will need to scale.

Details and best practices

In these tests, we send a high load of data and a large number of requests to the server to check response time and availability. We can also use it to validate and measure scalability for a major event like Black Friday.


These tests are an important way to measure and identify how much our application can respond to extreme conditions. Besides, this type of testing can help us choose a particular technology or programming language when developing our APIs.

Difficulties and Disadvantages

We don’t have great difficulties or disadvantages. Perhaps financially, since the test can consume more machine resources and if it has not been well configured, it can scale automatically, generating a high cost.



Verify that endpoints are responding at a time considered ideal by the team and identify points that are taking too long to respond. 

Example: We want to keep all requests responding at up to 400ms

Details and best practices

A lot of people confuse this test with the load or stress test. The goal here is not to check how much the system will hold, but rather how long a page, a screen or a request takes to complete.

These scripts are created to simulate some requests and take an average of that time. If the result is larger than expected, the test fails and the team checks for possible reasons to resolve and run the tests again.

Difficulties and Disadvantages

We don’t see any difficulties with Service oriented architectures (SOA) kind of test. We just need the environment we’re going to test to be the production or the closest to it. Why is that? Simple, searching a table with 100 records is fast, but with 1 million rows it can take longer and we need to ensure that the response time remains within the acceptable margin.

Identifying these bottlenecks and time will allow the team to act before and create indexes or change the modeling to solve this problem.


This test is critical to usability and therefore the success of an application. The user does not want to wait 5 seconds to change the screen, wants everything on time. It is also important for the success of the business itself since fast systems are ranked better on Google.

Test at the appropriate level

We’ve seen that several types of tests can be automated just as service oriented architectures(SOA) , if we write these tests for everything, the test runtime will be very high and unfeasible. Imagine every time you encounter an error you have to run all the tests again. No, not at all. For this, we need to think of a good strategy.

An efficient strategy of automated testing is to think of them as a pyramid, where at the base will be the fastest and least costly tests and on top of the slowest and most expensive ones, such as manuals. This model was proposed by Mike Cohn in the book The Forgotten Layer of the Test Automation Pyramid.

So at the base, we have a lot of unit tests, because they are faster to perform. Followed by integration and functional tests on a slightly smaller scale, since they are still of great importance, but have more dependencies and require a longer time. And finally, to a lesser extent, interface and manual tests

Who is responsible for writing each type of test?

It may seem not, but the answer to that is very simple. The whole team.

We need to stop pushing the responsibility of the test onto other teams, other people. The team as a whole is responsible for this. If you don’t know how to call someone, create the tests in pairs. Quality professionals can help developers in unit testing, as well as business analysts, it’s not just the developer’s responsibility. Just as it is not only the responsibility of the quality professional to test every requirement and business rule.

We need to stop taking ours off the line and just stay in our comfort zone and start calling the team to teach us and help us at every point. Call the quality professional, the business analyst, security. Call the developer. Let’s understand the problem, features, requirements, and seek quality together. Everyone has only to win.


We have seen the main types of tests through Service oriented architectures (SOA)on automation testing and strategies that we can use to ensure the quality, safety, and integrity of our system. We also saw that the responsibility for quality lies with the team as a whole, together and not in a specific area.

As testing increases, the confidence of the company as a whole increase from the code we write. This gives teams more freedom to refactor, create, and experiment, whether with new ways of developing new languages, or new architectures. That’s because everyone knows you’re not going to break anything, you’re only going to have advantages.

Share this