implementation of command test

[AngeloChecked]

The "test command" serves to run the test runner and gather feedback from the test suite concerning the overall status of our program.

Different programming languages and ecosystems use a range of approaches to tackle this task. Some use external tools, while others integrate it into their toolchains. Certain ecosystems rely on third-party libraries, and there are those that aim to standardize the process as much as possible.

This current implementation is limited to utilizing/embedding (this) the existing testing system and providing a user-friendly interface through the Steel CLI. This enables running tests in the module's working directory or choosing specific tests to run.

we can using the command in this ways:

steel test   # run the tests in the current directory
steel test . # equal to above
steel test contracts/contract-test.scm # run only test of the selected file

note

• To make this work, I had to adjust the import path of test-runner.scm, but it doesn't appear to be a concern.
• To ensure that the external file test works correctly (now they must provide something to works), we must address the tree-shaking issue we previously discussed #84 .

I welcome all feedback and suggestions for improvement

[mattwparas]

This looks good! Per needing to have a provide - I have addressed the tree shaking issue - now the test runner actually only calls require on files that actually have a provide. Reason being, I had no other way to delineate an application .scm file from a file meant to be used as a library, without consulting some other kind of file such as the cog.scm. For the first iteration here though, I think the existing behavior is fine as is as long as we document that this will only attempt to require files with provides.

Any thoughts on that?

[AngeloChecked]

This looks good! Per needing to have a provide - I have addressed the tree shaking issue - now the test runner actually only calls require on files that actually have a provide. Reason being, I had no other way to delineate an application .scm file from a file meant to be used as a library, without consulting some other kind of file such as the cog.scm. For the first iteration here though, I think the existing behavior is fine as is as long as we document that this will only attempt to require files with provides.

Any thoughts on that?

Yep, for the initial iteration, I believe this is good enough.

in your opinion, should we consider printing a message after the steel test to provide a warning about it?

[mattwparas]

I think just add a little flavor for the doc text of steel test - so instead of just "test the module" we could include something like:

"Tests the module - only tests modules which provide values" or something of the sort

Otherwise - looks good to me, once you make that update we can run the pipeline, I'll approve and we can merge

[AngeloChecked]

done