Improve tests

[geyslan]

1. Explain what the PR does

a2ec86e chore(test): enhance tests using t.Parallel()

Utilize t.Parallel() in unit tests to enable concurrent execution. This
takes advantage of multiple CPU cores, reducing the overall test suite
runtime.

Critically, this practice elevates the detection of insidious race
conditions and state leakages—issues that often remain concealed during
serial test execution.

9b6d344 chore(Makefile): enable '-shuffle on' for random

By using '-shuffle on' we can run the tests in a random order, which
helps us to find any unintentional inter-test dependencies or state
leakages.

2. Explain how to test it

make test-unit
make test-types
sudo make test-integration

3. Other comments

Currently, the use of t.Parallel() doesn't affect the performance of the tests (slight difference):

main:
make test-unit  43,27s user 11,96s system 320% cpu 17,249 total

PR:
make test-unit  43,74s user 11,34s system 325% cpu 16,944 total

[rafaeldtinoco]

Currently, the use of t.Parallel() doesn't affect the performance of the tests (slight difference):

Where ? In runners or your local environment ? Because if in a SMP environment we aren't benefiting from having it set, we shouldn't set it IMO.

[geyslan]

Currently, the use of t.Parallel() doesn't affect the performance of the tests (slight difference):

Where ? In runners or your local environment ? Because if in a SMP environment we aren't benefiting from having it set, we shouldn't set it IMO.

Local tests shown 1s of improvement, in average, that's why I put that it didn't affect the performance. On Github workflow is slightly similar. But as I pointed in the commit:

Critically, this practice elevates the detection of insidious race
conditions and state leakages—issues that often remain concealed during
serial test execution.

The main reason for using t.Parallel() is to have more checks (i.e.: DATA RACE) when building unit tests.

[rafaeldtinoco]

The main reason for using t.Parallel() is to have more checks (i.e.: DATA RACE) when building unit tests.

Fair enough.