Provide a way to test custom moves

[greyhairredbear]

Basically what the title says. We have several custom moves to enable changing Pickup and Dropoff actions within the same move and it would be very nice to have some tests for the whole move and not just our extracted index calculation logic.

I guess something like testSolution.performMove(move) or something similar should be sufficient for us. I suppose asserting the state of the solution and shadow variables after the move is something we would do with the assertion library of our choice.

I've already mentioned it on reddit a while ago and got a response from Geoffrey that this is WIP. I also did see #1349, which I guess is related to this (or maybe a prerequisite).

In case any help is wanted with this and it's feasible to have an external contributor there, I'd be happy to collaborate here (got a bit more spare time in the months ahead, so I figured this might be interesting to spend my time with 🙂 )

[triceo]

There is a fork in the road here:

• Do this for the existing move selector API.
• The PR you are referencing is a start of a brand new subsystem of the solver (also called "move streams"), that will replace the current move selectors. But it will take a very long time to deliver. And even when they're delivered, move selectors will still remain around for a long time, even though they will be deprecated.

Considering that move streams is very much a moving target with an uncertain delivery date relatively far in the future, I would recommend thinking in terms of the existing move selector API. Whatever is done for that though will eventually get deprecated, when move streams becomes a thing, and brings its own testing harness.

Since move selectors are currently not at the center of attention and we no longer see a way how we could evolve that framework, I can see a testing harness being developed as a community contribution. We would not be causing conflicts for one another, because move selectors aren't being actively developed anymore - therefore there would be no pressure on the community contribution, and it could evolve at its own pace.

[greyhairredbear]

I see, thank you for the information. Even though working on a feature that is bound to be deprecated is probably not the most glorious thing to do, it would still provide some value for our test suite, so I guess I could take a look at it.

Do you have any thoughts on the API design or on potential pitfalls when implementing this? Does a separate testing harness class like ConstraintVerifier (only for solution updates) make sense here? (I guess this class would wrap some Timefold-internals to perform the move on a solution...)

[triceo]

My first thoughts are:

• The harness doesn't even need to be that much code. What you need is a way to run the move on a solution, and then also a way to undo that move. So, a thin wrapper around the MoveDirector/ScoreDirector.
• The effects on the solution can be checked using a standard testing framework, no need to implement any custom assertions.
• The harness should be injectable in Quarkus and Spring Boot, much like ConstraintVerifier is.

IMO that is all when it comes to requirements. When it comes to API, I'll leave that with you - to me, that's the most interesting work and I wouldn't want to rob you of it. When you have an idea, come back and we can discuss it.