Service-Oriented Architectures (SOA) on Automation testing

https://appsierra.com/service-oriented-architectures-soa-on-automation-testing/

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.

UnitObjective:

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.

IntegrationObjective:

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 safetyObjective

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.

FunctionalObjective:

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.

Hello. I am a student and taking knowledge through internship about digital marketing.