search

scotws / TaliForth2

A Subroutine Threaded Code (STC) ANS-like Forth for the 65c02
Other
86 stars 23 forks source link

Reorganize test folder and test files #227

Open scotws opened 5 years ago

scotws commented 5 years ago

The testing folder could be reorganized - Gforth tests should go in their own file (having them run as "Tali" is not polite), there might be some logical way to split up the core.fs files. Another idea might be to put the tests in a folder so the test programs just "run everything in the folder" so we don't have to edit lists by hand.

In the far future, a rewrite of talitest.py could include the parallel execution of the tests with a command line option to switch back to current sequential behavior if the user insists, absorbing the current shell script.

SamCoVT commented 5 years ago

I'm just going to put some notes here for when I get to this after the 1.0 release:

Merge string.fs and stringlong.fs tests into a single file. They are both short enough they will be better in a single file.

Remove the core.fs file as it is now replaces with core_a/b/c.fs

Consider separating all of the Gforth tests out of the tali.fs tests (renaming the file might be appropriate too).

Move all of the actual tests into a folder and make it so all tests in that folder get run, even if they are new. Some creative naming (like 01_core.fs to 99_cycles.fs) might help in enforcing the order of the results in results.txt.

Update the documentation. Show how to run parallel tests as well a series tests and describe the new organization.

scotws commented 5 years ago

For the record, calling nice -n 19 ./ptest.sh as expected runs all talitest.py instances with the lowest priority of 39, so the machine actually gets stuff done. I don't think we want to force this on the user, but we should probably mention this in the docs.

scotws commented 4 years ago

This might be something we want to work on as part of the new modular system?