Make it easier to write tests involving fixed timesteps

[janhohenheim]

Objective

• For running tests involving fixed timesteps, I want to advance the time so that every call to app.update() triggers a fixed update
• Right now, the most precise way to do that to my knowledge is

  app.insert_resource(TimeUpdateStrategy::ManualDuration(Time::<Fixed>::default().timestep()))

• But this is a bit clumsy, and also doesn't work when the fixed timestep isn't at the default. Some more boilerplate would be needed in the test setup to deal with that:

  app.insert_resource(TimeUpdateStrategy::ManualDuration(app.world().resource::<Time<Fixed>>().timestep()))

• Good luck adapting this for the case when the fixed timestep ever changes at runtime lol

Solution

• Create an alternative strategy called TimeUpdateStrategy::FixedTimesteps that advances time by the fixed timestep automatically:

  // Now `app.update()` will run the fixed loop exactly once!
  app.insert_resource(TimeUpdateStrategy::FixedTimesteps(1))

Testing

• None, as this is trivial

[Ownezx]

Perhaps making sure that the u32 is non zero would avoid silliness?

That being said it's clear enough that zero would likely not be used.

[Jondolf]

approved on behalf of @NiseVoid

[janhohenheim]

[janhohenheim]

@Ownezx well, 0 is a valid state here: using 0 will in fact ensure that the fixed timestep is never run. Might be useful for disabling fixed updates in a test? Though it would also not advance time at all, so idk how useful that would be in practice.