Fix async

[antonio-gg-dev]

📚 Description

Replace this text with a short description of your feature/bugfix.

🔖 Changes

• List individual changes in more detail

✅ To-do list

• Make sure that all the pipeline passes
• Make sure to update the CHANGELOG.md to reflect the new feature or fix

[antonio-gg-dev]

@Chemaclass and I have undergone a refactor to extract the application's state logic into a separate file (commit c50b5f7). After this, we tested various systems, providing a brief report on each one:

• tmpfile: We encountered race conditions. Two subprocesses read and wrote the file at the same time, and the last one to write was the winner.
• mkfifo: This one initially seemed to work perfectly during a test, but after that, the process began to hang, throwing errors that the files already existed. It seemed the best choice but stopped working unexpectedly.
• shm: The same issue as with tmpfile arose, but the execution was much faster since data storage was in RAM.
• shm + flock: This is the implementation currently in the latest commit (2adae5e), though it's only implemented in the passed_tests. When trying to implement it for the entire state, the tests began to fail. The reason needs a deeper investigation.

Having said that, we've left the work half done for today in case anyone wants to investigate further. In the worst-case scenario, if we decided to abandon the asynchronous execution feature, we could at least retain the extract state refactor.

I would like to add that even if we implement a system compatible with asynchronous operation, I believe we should insert an 'if' in all getters and setters to use the implementation from commit c50b5f7 (which simply uses variables) if the user runs the tests synchronously, as it seems to be the fastest implementation of all.

[antonio-gg-dev]

@Chemaclass @khru Can you help me with the test test_when_running_bashunit_without_error_then_exit_code_should_be_success? It suddenly broke, and I don't know why. That's the only thing left for me to remove the draft.

[khru]

@Chemaclass @khru Can you help me with the test test_when_running_bashunit_without_error_then_exit_code_should_be_success? It suddenly broke, and I don't know why. That's the only thing left for me to remove the draft.

@Tito-Kati I think for some reason now it's returning this
Your branch:

Main

I've tested like this:

function test_when_running_bashunit_without_error_then_exit_code_should_be_success() {
  t="$(./bashunit)"
  echo $t
  assertSuccessfulCode "$(./bashunit)"
}

[antonio-gg-dev]

It's true that it's a bit odd to run the command without specifying the files to test. How should we proceed? @khru @Chemaclass

[khru]

Personally I don't have a preference, I like that if it doesn't give you a file it tells you executed 0 files, but I don't care if the final result doesn't appear because we are already saying that we have nothing to execute. But I do think should end with an exitcode 1.

Maybe see how jest and PHPUnit behave could help us

[Chemaclass]

I would say that if you dont pass any arguments (path to run) it should do an exit 1, but I wouldnt bother a lot about this right now. We will luckily change this implementation later, when we could define in a config file the path, so you could run bashunit without especifying all the time the path, because it will read it from the config. So, I wont consider this a blocker for this PR.

[antonio-gg-dev]

So... removing that test?