If you need to perform database testing, you will meet the acronym ACID anyway.
What does it mean and what can it be used for?
We’ll talk about this further in this article.
What does ACID mean?
So ACID refers to a special set of requirements that can be used for saving information blocks.
This distinctive feature is very important for financial transactions and other fields where a big amount of personal information/financial resources are added to systems and this is a popular way to perform performance testing in many testing companies.
Further, we’ll try to analyze why one repository is better than 10 separate files and why using one transaction is safer than 10 separate requests, by explaining each letter of this abbreviation.
Atomicity helps us to be sure that any made transaction will be executed completely. There is no intermediate state.
For example, you need to send your friend some money. When money is transferred through online banking, the following events happen:
- Your money are withdrawn;
- Your friend receives them on his/her bank account.
Now let’s imagine that we have 2 different requests. When bugs appear, the following situations can happen:
- A user doesn’t have enough money on his/her bank account – a system shows an error message, there is no need for atomicity;
- A payee’s bank card is blocked/it expires – the request is canceled.
And if an error at the first stage has no consequences, an error at the second one can result in losing your money.
Atomicity helps to structure requests and show the interaction between them. And if there is an error in one of them, each one should be rolled back.
This feature comes from the previous one. Thanks to the fact that a transaction doesn’t allow intermediate results, a DB is always consistent.
For example, if a user completes a personal card in a system:
- Full name;
- Date of birth
The software database contains a few tables that are connected:
Therefore, when a client completes a card, three requests with data are sent to a system.
Atomicity ensures all input data will be saved (it’s impossible that a phone will be saved and initials – will not.)
This could have made a DB inconsistent, some attributes will blow in the wind and this can lead to the bug appearance.
A developer is responsible for the correctness of consistency. It’s because it refers more to business logic than to technologies.
When one transaction is made, all other transactions should not affect it.
If a system is made for one user — everything will be good but what if there will be numerous users?
In this case, you’ll need to run parallel tests so that a system could work at an accelerated rate.
But this can result in unpleasant pitfalls:
- Problem 1 — a lost record;
- Problem 2 — repeated reading;
- Problem 3 — dirty reading;
- Problem 4 — a phantom.
To solve all these problems you need to use an isolated transaction.
How can you reach this?
For example, use version block.
This means blocking a certain line in a table (you can block either data from adding or editing).
At the end, if a user receives verification from a system that the required transaction was successful, he/she can completely be sure that all changes he/she made won’t be stopped due to an unexpected failure.
No electricity, problems with an Internet connection?
This should not affect the transaction that has been made.