How do I (integration) test custom variable listeners to ensure no score corruption is happening?

Context

I'm currently facing the issue that after a fix for some business logic in my variable listener, said listener is causing score corruption. I have a very general integration test to avoid breaking our solution for that in place. It just takes an example and solves in FULL_ASSERT mode.

However, the score corruption seems to only occur under quite specific circumstances, that's why im currently looking for a way to extract and test this scenario in a more isolated fashion. I suppose this would

help with debugging
allow for more specific tests

Question

How would I write tests that

sets up a working solution (figuring that out myself probably won't be an issue)
performs one or more specific moves on that solution
asserts no corruption has occurred
asserts expected values for the shadow variables (figuring that out myself probably won't be an issue)

In general, I think I'm most interested in the part where I'd simulate creating and performing moves to trigger the listeners.

Notes:

I've seen the test code for CustomVariableListeners, ListVariableListeners and ChangeMoves. I'm wondering if something like these tests would be the recommended way to achieve what I'm after.
This question might be related to some degree, but it currently doesn't have any answers

Solution

The official answer is that there is no way to do this in a supported, public API.

You've already figured out the unofficial answer - if you create instances of the AbstractScoreDirector, you will be able to simulate every scenario by running the before/after...() methods on the instance. This is internal API though, any may change at any time and without warning.

We are aware that neither of these answers are satisfactory. Variable listeners are a complex business, and one thing we keep on our agenda is making them much easier to deal with. When that happens - and at the moment, there is no set timeline for that - you'll be able to test them in isolation, and using a fully supported API.