The need for this function isn't immediately obvious and it feels like a bit of a hack. In general if an API needs to be changed to support a test you have one of two things going on: (i) your test is too invasive and checking too much internal logic; (ii) the API doesn't expose enough information.

In this case I think it's (i). I think it can be changed relatively easily as this and callFunctions have the same signature. It might be possible to change the tests to call callFunctions instead (as they have mock mode turned on). You can then add a check to make sure the underlying function calls have been disaptched to the expected hosts.

If this isn't possible, then we need to work out what's happening in callFunctions that doesn't work properly in mock mode.

Yes, switching to callFunctions is pretty easy with the only caveat that we need to use the TestExecutor and TestExecutorFactory classes that currently lived in ./tests/tests/scheduler/test_executor.cpp.

I have moved the declaration of these classes to fixtures.h and kept the definition where it is.

I also add a check for the recorded messages in the function call client.

I think these tags are getting a bit too granular. Admittedly the util tag is bloated, but as mentioned above, these tests are really testing the scheduler, so once they've been moved, they can be added to the [scheduler] tag. The usefulness of the tags is to allow someone to quickly run the tests related to the thing that they've changed, however, when they're this granular, I'm not sure it's easy to work out which ones to run.

Catch2 provides various selectors that should make it easy to run subsets of tests in your dev workflow, if you're finding there are too many tests to run in a loop e.g. by file: https://catch2.docsforge.com/v2.13.2/running/command-line/.

I agree thanks. For future reference, you can run all tests in tests/test/scheduler/test_scheduling_decisions.cpp by running:

faabric_tests -# [#test_scheduling_decisions]

My gut here would instead be:

if(topologyHint == faabric::util::SchedulingTopologyHint::PAIRS &&
      nOnThisHost < 2) {
    // Move on if we can't colocate function with at least one other
    continue;
}

I think this fixes the issue you mention in the PR description too.

I don't think this would behave as expected. For example:

• We have 4 hosts with 4 slots each.
• We want to schedule 9 requests (with the NEVER_ALONE hint).
• We expect 4 requests scheduled to the first host, and 5 scheduled to the second.

However, I think your solution would schedule 5 requests on the first host and 4 on the second, as it would exhaust all possible hosts (nOnThisHost == 1 for all of them), and resort to overload the master.

After an offline discussion, I use this change together with a change in the overloading logic that makes the issue mentioned in the description disappear.

Changes here involve moving from a class declaration + definition to just definition and some forceLocal refactor.

I add this test that before would have failed with NEVER_ALONE.