[code-reflection] RFR: More systematic binary op tests

Hannes Greule hgreule at openjdk.org
Mon Apr 8 19:43:26 UTC 2024


This is more of an experiment to gather some opinions. Please let me know what you think.

With this change, I'm trying to cover interpreter and bytecode generation/execution of binary ops in a more systematic approach.

I didn't find a good way to automatically *generate* test cases, especially as there is insufficient information about allowed types. Therefore, this approach consists of two main steps:

1. A test that ensures that all bin ops have at least one test case
2. Dynamic tests based on these test cases

Note that these tests currently all fail. It seems like neither the interpreter nor the bytecode generator can deal with invokevirtual methods properly, so unboxing always fails.

## Alternatives

One other idea I had was to, instead of going through the dynamic test cases, go through all methods in that class annotated with `@CodeReflection` and check this way if all bin ops are covered. This might allow for more extension to e.g. unary ops. The rest of the tests would then work as in other test classes. The problem of different data types and values would still exist though. Maybe a property-testing approach like `jqwik` would help with different values.

-------------

Commit messages:
 - reorder, add more bin ops, address comments, clean up
 - implement ParameterizedTest based with interesting inputs
 - fix
 - Merge branch 'refs/heads/code-reflection' into test/binaryoptests
 - Implement different approach
 - initial design

Changes: https://git.openjdk.org/babylon/pull/40/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=40&range=00
  Stats: 293 lines in 1 file changed: 293 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/40.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/40/head:pull/40

PR: https://git.openjdk.org/babylon/pull/40


More information about the babylon-dev mailing list