Hi Guys,
I’m working on the issue https://github.com/apple/foundationdb/issues/258 and we need to add junit test in java api.
The compilation of junit tests aren’t included in local.mk
In bindings/java there is only one junit test (ArrayUnitTests) and it is not fully implemented. So I think that’s why junit tests aren’t compiled.
Is it ok to annotate the testcases (which aren’t implemented) in ArrayUnitTests as @Ignore and enable the compilation of junit tests?
Thanks,
Vruyr
I think @ajbeamon or @alloc would be the reviewers for this, so I’ll let them give you an answer.
I can’t imagine we’d adopt a “no tests” policy though. 
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.
I’m dredging up some old memories here, but I recall the specification for the stack machine requires reading instructions that are themselves stored as packed tuples, and are unpacked by the tuple layer of the binding being tested. Some of the operations (like SWAP or SET) seem like they would preclude symmetric errors like you’re talking about. I guess the operands are encoded as byte strings, not strings, but my assumption is that most/all implementations use the same code path for both types, just swapping in a different type code.