Service-Oriented Architectures (SOA) on Automation testing


What is Service-Oriented Architecture (SOA)?

Service-Oriented Architecture (SOA) is a software design technique that comprises 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 in the software industry. However, as the architecture changes evolve, testing techniques need to evolve together.

Before technology developed to levels we are at today, our problem was simple. We had a system that was based on the session. We could test our components individually and had a quality team.

Nowadays, it is very common to work based on the 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 are 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.

Why should we test the whole SOA?

The answer to that is simple. Suppose you changed some business rules or 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?

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

As your business grows and teams grow, communication difficulty increases and not everyone involved is acutely aware of the changes that some other team has made.

The idea of testing the whole is to ensure that no broken code goes up to production and affects too many services or, in the worst-case scenario, the application itself. By using technology like this, we’ll know about the problem before it happens, and the teams involved can change it in 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.

Unit

Objective:

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 behaviour 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.

Advantages

  • Clean code
  • Easy to maintain with low coupling and high cohesion
  • Guaranteed application of business rule over time
  • The fastest type of test you can run

Difficulties and Disadvantages

By using several mocks and simulations, tests are not able to identify all possible errors and the results are often far from reality. For this purpose, we have the Integration Tests.

Integration

Objective:

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. Users and testers get 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 instance.

Advantages

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

Risk or safety

Objective

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.

Advantages

  • 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. The problem is that most people don’t have the time or expertise to think of all the ways their API can be attacked.

Functional

Objective:

Validate the final behaviour, 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.

Advantages

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.

Regression

Objective:

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.

Advantages

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

Objective:

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.

Advantages

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. Financially, perhaps, since the test can consume more machine resources especially if it has not been well configured.

Performance

Objective:

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 tests. 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 modelling to solve this problem.

Advantages

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 not be feasible, either professionally or financially. 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 pyramids. This is where the base will represent the fastest and least costly tests and the top will represent 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. These are 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 which, unlike integration tests, are performed on a significantly larger scale.

Who is responsible for writing each type of test?

The answer to that is very simple. The whole team.

We need to stop pushing the responsibility of testing onto the other teams and 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 a lot in unit testing, as well as business analysts. You need to remind yourself that 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 shirking our duties and stay in our comfort zone while calling the team to teach us and help us at every point. Let’s understand the problem, features, requirements, and seek quality together. Everyone has to win.

Conclusion

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 increases too. It gives teams more freedom to refactor, create, and experiment whether new ways of developing languages or newer architectures can bring them more innovation or give them the opportunity to make their work count.