Simplify tests for std

[Mte90]

Right now is a rust file https://github.com/Ph0enixKM/Amber/blob/master/src/tests/stdlib.rs

I think that can be handy to have a single file to compare for the bash output for every case, in this way is more easy to maintain and develop.

So the next step tomorrow can be to test the various bash script generated and running them like in a sandbox like with https://bach.sh/ In this way we can write the unit tests in Bash (or Amber itself).

[Ph0enixKM]

What is the main problem? The hard to read test code?

[Mte90]

For someone that doesn't know Rust is not easy and also requires to compile it again.

[b1ek]

if we are switching to a new framework, it will have to be compatible with cargo test as well. probably adding a wrapper test function should do the thing

[Mte90]

I think that we can split the test stuff in 2 part:

• The one needed by Amber for internals
• The Bash generated to be always the same
  • Second step can be also test the various Bash generated

[Mte90]

So looking on how tests are made right now, I think that a solution can be:

• Create a test called idosomething
• There will be idosomething.ab that is the script to execute
• Also idosomething.txt that include the output that the other script should have

In this way is more simplier also can be useful to not build every time Amber if there aren't changes to rust files.

[Ph0enixKM]

Or we could also:

module/
    module.ab
    module.in.ab
    module.out.txt

where module.in.ab contains the test code and module.out.txt contains stdout

[Mte90]

Yeah sure, I think a file for every test is more simple to manage as it is clear from the filenames

[Mte90]

Looking more, we can do:

• module/
  • module.ab/.rs
  • module.out.txt

Amber will check on compile for rs files and for second if a Amber file exist, in this way if it is needed Rust we can use it.

[FedericoCeratto]

Why the need to execute the generated scripts? When testing a compiler (or a linter, a minifier, etc) the input is a block of code and the output a [byte]string (binary, IR, etc) that needs to match an expected value. In the case of Amber manually checking the expected output is particularly easy as it's [ba]sh.

[Mte90]

Why the need to execute the generated scripts? When testing a compiler (or a linter, a minifier, etc) the input is a block of code and the output a [byte]string (binary, IR, etc) that needs to match an expected value. In the case of Amber manually checking the expected output is particularly easy as it's [ba]sh.

Test the generated scripts is an idea to detect if the bash generated doens't have syntax issues.

[Mte90]

I was able to implement the feature https://github.com/Ph0enixKM/Amber/pull/238 and I am looking for feedback before to migrate all the tests in dedicated files.

Maybe before to proceed it's the case to merge https://github.com/Ph0enixKM/Amber/pull/185 and https://github.com/Ph0enixKM/Amber/pull/216 so we can migrate them just once.