Mirror of CollapseOS
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 2.0KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849
  1. # Testing Collapse OS
  2. This folder contains Collapse OS' automated testing suite. To run, it needs
  3. `tools/emul` to be built. You can run all tests with `make`.
  4. ## zasm
  5. This folder tests zasm's assembling capabilities by assembling test source files
  6. and compare the results with expected binaries. These binaries used to be tested
  7. with a golden standard assembler, scas, but at some point compatibility with
  8. scas was broken, so we test against previously generated binaries, making those
  9. tests essentially regression tests.
  10. Those reference binaries sometimes change, especially when we update code in
  11. core libraries because some tests include them. In this case, we have to update
  12. binaries to the new expected value by being extra careful not to introduce a
  13. regression in test references.
  14. ## unit
  15. Those tests target specific routines to test and test them using
  16. `tools/emul/runbin` which:
  17. 1. Loads the specified binary
  18. 2. Runs it until it halts
  19. 3. Verifies that `A` is zero. If it's not, we're in error and we display the
  20. value of `A`.
  21. Test source code has no harnessing and is written in a very "hands on" approach.
  22. At the moment, debugging a test failure is a bit tricky because the error code
  23. often doesn't tell us much.
  24. The convention is to keep a `testNum` counter variable around and call
  25. `nexttest` after each success so that we can easily have an idea of where we
  26. fail.
  27. Then, if you need to debug the cause of a failure, well, you're on your own.
  28. However, there are tricks.
  29. 1. Run `unit/runtests.sh <name of file to test>` to target a specific test unit.
  30. 2. Insert a `halt` to see the value of `A` at any given moment: it will be your
  31. reported error code (if 0, runbin will report a success).
  32. ## shell
  33. Those tests are in the form of shell "replay" files. Every ".replay" file in
  34. this folder contains the contents to type in the shell. That contents is piped
  35. through the shell and the output is then compared with the corresponding
  36. ".expected" file. If they match exactly, the test passes.