Add Testing Utility for Swarm

[maennchen]

We recently changed a big part of the supervision of quantum (add job scheduler library) to swarm if it is used in a cluster.

One thing that was missing for us is a testing utility to make sure that the new callbacks for swarm actually work.

I implemented a really easy helper: https://github.com/quantum-elixir/quantum-core/pull/369/files#diff-51021d33872c9243af9315e6b3809e77

Would you be willing so add something like that (but more complete) to the library?

[bitwalker]

That'd be great!

[arjan]

I'm :+1: , the question is where we would put this utility. Swarm.TestHelpers maybe? PRs welcome :-)

[maennchen]

I think we should start by defining what those would contain.

Those are the things that come into my mind:

• Help supervising multiple workers in ExUnit (since start_supervised doesn't work together well with workers that could stop / have the same modulename to start
• Provide Utility to initiate Handoff
• Provide Utility to initiate Conflict Resolution

[maennchen]

BTW: I would also include a Swarm.TestCase that does two things:

• Import all Test Helpers for convenience
• "Warm Up" swarm in a setup block so that it is already fully ready before any tests start. This can help prevent some timeout issues.

With warming up I mean to block & wait until swarm is fully synced.

[arjan]

Yes, well actually @bitwalker and I are planning to refactor all test cases to make Swarm setup more reliable and less work, using his https://github.com/bitwalker/ex_unit_clustered_case library. So maybe hold off doing anything big until this has settled.

[bitwalker]

Yeah, revisiting this after thinking on it a bit more, I think a lot of what we have planned with reworking the existing test suite covers the goals stated here. Namely, we would be in a position to test handoff and conflict resolution much more easily, amongst other things. The other big thing coming down the pipe is reworking Swarm to no longer be a singleton process, which would allow us to simulate some things in parallel when we don't need to spin up a cluster of nodes for that purpose.

I will leave this open for now though, and we can revisit once some of these changes are in place.