How to test OPA policies when using the WASM target? Is there an equivalent of OPA CLI policy testing.

[pkkhokhar]

In OPA, policies written in Rego can be tested using Rego test rules (for example, rules prefixed with test_) and executed with the OPA CLI. These tests assert expected policy behavior and are commonly used as unit tests during development and when compiling bundles for server-side use.

However, when policies are compiled to WebAssembly (WASM) and embedded in another application, it’s less clear how this testing workflow translates.

Is there a way to run or validate Rego tests against policies that have been compiled to WASM, or is the recommended approach to test policies before compilation using the standard OPA test tooling?
There is this option use opa test -twasm, for having the same tests evaluated via the wasm evaluator but will this be enough to validate that this SDK would be compatible with the wasm bundle?

Can the opa-java-wasm SDK be used to load and execute a compiled WASM policy in tests to validate that it behaves correctly at runtime?

Are there recommended patterns, tools, or best practices for integration or end-to-end testing of OPA WASM policies using the Java SDK?

[andreaTP]

Hi @pkkhokhar and thanks for your interest in this project! Interesting question!

We haven't done, so far, any attempt to integrate OPA test tooling in this project.
I'd say that, currently, the recommended approach is to follow the upstream guidelines and tooling i.e. opa test machinery.

If you notice any difference in behavior it's a bug and I encourage you to report it opening an issue here.

will this be enough to validate that this SDK would be compatible with the wasm bundle?

Excluding "SDK specific" builtins, yes, even using it without -twasm.

Can the opa-java-wasm SDK be used to load and execute a compiled WASM policy in tests to validate that it behaves correctly at runtime?

This is something that can be considered in the longer term, I'd like to see a strawman or proposal on how it can look like.

Are there recommended patterns, tools, or best practices for integration or end-to-end testing of OPA WASM policies using the Java SDK?

Just refer to the official documentation, nothing specific comes to mind.

[pkkhokhar]

Hi @andreaTP ,
Sure we will report any differences we will observe going forward and reply on opa test results till then.

One more thing i would like to discuss is this:

We’re using the OPA Wasm runtime and noticed that execution is currently single-threaded, which has become a scalability limitation for us.

We’re interested in contributing in this area and would like to start a discussion before proposing changes.

Areas we’d like to explore:

1. Supporting multi-threaded execution in the Wasm runtime and for that introducing an object pool for Wasm policies

Potential approaches: fixed-size thread pool or dynamic thread pool

Open to alternative designs or recommendations

2. We’re also seeing memory spikes when refreshing the policy pool at runtime and wanted to ask:
   If this is a known behaviour
   Whether there are existing benchmarks or memory tests we could reference

We’d appreciate guidance on whether these ideas align with the project’s direction, and pointers to any prior discussions or docs.

If helpful, we’re also happy to connect live to discuss further.

[andreaTP]

Sure we will report any differences we will observe going forward and reply on opa test results till then.

🙏

fixed-size thread pool

I have been discussing and entertaining this idea multiple times now, I'm convinced is the way forward!
Here you can find one recent writeup.

I think we have 2 subjects here:

• implementing an OpaPolicyPool that dispatches the actual evaluation to a pool of instances: I'm happy to review an implementation if you want to contribute or I can eventually propose one myself. The important aspect is to measure on a live system the perf at scale and seems like you have the infrastructure in place for doing it.
• memory spike on refreshing policy: here I need to understand better the use case, the "most efficient" setup would be using the Chicory's build-time compiler, but, in this case, you need a restart to load a new policy. We also have an experimental "on disk cache" that might help, but it really depends on the details(contingency etc.).

To connect live, the easiest would be to show up at the Office Hours and/or join the Zulip channel for more synchronous interactions.