We don’t really use our JUnit tests. As you’ve noted, they aren’t compiled, and also, they aren’t run in any way.
Are you also changing the build to add some kind of dependency manager (e.g., maven or gradle) and use that in the build, because I’m not sure how else you would get JUnit installed to run the tests… I suppose you could check the jar into the repo (yikes) or depend on a local installation of JUnit (probably a bad idea) or roll your own solution to download the dependency.
If you do come up with a sensible solution for that, I don’t think we’d be opposed to marking all of the tests that are failing for lack of implementation as ignored, because they aren’t really helping anyone.
I’m also not sure how much utility we’d get from a JUnit unit test, tbh, given our current testing setup. (Though I wouldn’t necessarily be opposed to some JUnit tests that run on every build, especially if it would be useful in guaranteeing properties that our current tests are the best at detecting.) We have a few files in the “test” subdirectory that are just ad hoc tests that we can run when we feel like it. The tests we actually run are the bindingtester tests. The implementation for that is in StackTester and AsyncStackTester. There are some tests of the Tuple layer in there, including some tests to make sure that they handle double and float conversion correctly and that they usually transform things the way that is expected. However, because reasons, it’s difficult to use that test to protect against errors that are symmetric in the encoding and decoding. For example, imagine that the integer encoder had an off-by-one error where x got encoded as x + 1 according to the spec, but the decoder had the equivalent opposite error, i.e., what should be y according to the spec is y - 1. Then the decoder/encoder tests will happily do the right thing. (There is sum amount of effort to tests integers in particular, but I’m not sure that, for example, a string decoder/encoder implementation that performed rot13 on all ASCII characters would characters would fail the bindingtester.)
It might make sense to write your test somewhere (maybe a new and improved TupleTest.java that had a functional test argument–and we could move the “main” methods of Tuple.java and TupleUtil.java to there as well) and then call it from the UNIT_TESTS instruction implementation (if it isn’t too slow a test). If you get a full test system working that integrates well with the rest of our build system, that would be nice, too.