You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not yet relevant, but the ordering of the phases depends on how unittest discover does things. Ideally, we want the phase tests to be run in the order of dependency within the compiler (ex. scanner -> parser -> semantic analysis -> etc.). In this way, if the compiler under test has a bug in an earlier phase we don't test a later phase first (and mislead the user that the error occurred in the later phase).
The text was updated successfully, but these errors were encountered:
Temporary fix was to enumerate the tests in order in bin/run_harness. This is actually a decent solution, if it wasn't for the error prone enumeration. A better solution is having bin/run_harness delegate to simple_test.main, which can do introspection on its module to find tests (and perhaps provide some args for nice programmatic test settings--like disabling passing CST tests a la #14).
0963158 has a better solution. run_harness now delegates to simple_test.main, which can have a lot more smarts. Currently, by default the order is explicitly enumerated in simple_test.main (automatic enumeration as mentioned above would still be nice). The user also has the freedom to specify which suites to run (and can run them in any order). For example:
# Runs cst, ast, symbol table, and scanner (in that order)
$ bin/run_harness cst ast st scanner
Not yet relevant, but the ordering of the phases depends on how
unittest discover
does things. Ideally, we want the phase tests to be run in the order of dependency within the compiler (ex. scanner -> parser -> semantic analysis -> etc.). In this way, if the compiler under test has a bug in an earlier phase we don't test a later phase first (and mislead the user that the error occurred in the later phase).The text was updated successfully, but these errors were encountered: