Integration Tests incorrect

[gschup]

Integration Tests incorrect

[donedgardo]

I'd love to contribute for this.
In general can we get a conversation going on what should be tested instead?

As a person integrating this library into their bevy game I'd like to see that:

• Systems in the Rollback stage should run.
• Rollback Components get synced between two applications with active session between each other.
• Test simple integration (great for documentation) between bevy and the plugin.
• Enough test that make us feel confident on improving the code and internal systems.

The test in the link provided would be a good start, I would remove line

bevy_ggrs/tests/example_integration.rs

Line 29 in de32619

assert_eq!(frame_count1.frame, frame_count2.frame);

It is not expected that the two systems are completely in sync only that both system are being scheduled and executed.

Additionally the second test would be a good candidate for the integration test and rollback behavior's:

bevy_ggrs/tests/example_integration.rs

Line 35 in de32619

fn it_syncs_rollback_components() -> Result<(), Box<dyn std::error::Error>> {

Now with thanks to this helper function or something very similar, we can now also test frame by frame scenarios/edge cases:

https://github.com/johanhelsing/bevy_xpbd_jondolf/blob/0d2582fc9fb6a5324d50f922d933612a76461d30/src/tests.rs#L33

fn tick_60_fps(app: &mut App) {
    let mut update_strategy = app.world.resource_mut::<TimeUpdateStrategy>();
    let TimeUpdateStrategy::ManualInstant(prev_time) = *update_strategy else { unimplemented!() };
    *update_strategy =
        TimeUpdateStrategy::ManualInstant(prev_time + Duration::from_secs_f64(1. / 60.));
    app.update();
}

[gschup]

solved in #69 . we now have a nice basis to extend integration tests from if we wish to do so!