Property m_EnableTimeTravel

m_EnableTimeTravel

Enables "Time Travel" within the test, which swaps the time provider for the SDK from Unity's Time class to MockTimeProvider, and also swaps the transport implementation from UnityTransport to MockTransport.

This enables five important things that help with both performance and determinism of tests that involve a lot of time and waiting:

  1. It allows time to move in a completely deterministic way (testing that something happens after n seconds, the test will always move exactly n seconds with no chance of any variability in the timing),
  2. It allows skipping periods of time without actually waiting that amount of time, while still simulating SDK frames as if that time were passing,
  3. It dissociates the SDK's update loop from Unity's update loop, allowing us to simulate SDK frame updates without waiting for Unity to process things like physics, animation, and rendering that aren't relevant to the test,
  4. It dissociates the SDK's messaging system from the networking hardware, meaning there's no delay between a message being sent and it being received, allowing us to deterministically rely on the message being received within specific time frames for the test, and
  5. It allows tests to be written without the use of coroutines, which not only improves the test's runtime, but also results in easier-to-read callstacks and removes the possibility for an assertion to result in the test hanging.

When time travel is enabled, the following methods become available:

TimeTravel(double, int): Simulates a specific number of frames passing over a specific time period TimeTravelToNextTick(): Skips forward to the next tick, siumlating at the current application frame rate WaitForConditionOrTimeOutWithTimeTravel(Func<bool>, int): Simulates frames at the application frame rate until the given condition is true WaitForMessageReceivedWithTimeTravel<T>(List<NetworkManager>, ReceiptType): Simulates frames at the application frame rate until the required message is received WaitForMessagesReceivedWithTimeTravel(List<Type>, List<NetworkManager>, ReceiptType): Simulates frames at the application frame rate until the required messages are received StartServerAndClientsWithTimeTravel(): Starts a server and client and allows them to connect via simulated frames CreateAndStartNewClientWithTimeTravel(): Creates a client and waits for it to connect via simulated frames WaitForClientsConnectedOrTimeOutWithTimeTravel(NetworkManager[]) Simulates frames at the application frame rate until the given clients are connected StopOneClientWithTimeTravel(NetworkManager, bool): Stops a client and simulates frames until it's fully disconnected.

When time travel is enabled, NetcodeIntegrationTest will automatically use these in its methods when doing things like automatically connecting clients during SetUp.

Additionally, the following methods replace their non-time-travel equivalents with variants that are not coroutines: OnTimeTravelStartedServerAndClients() - called when server and clients are started OnTimeTravelServerAndClientsConnected() - called when server and clients are connected

Note that all of the non-time travel functions can still be used even when time travel is enabled - this is sometimes needed for, e.g., testing NetworkAnimator, where the unity update loop needs to run to process animations. However, it's VERY important to note here that, because the SDK will not be operating based on real-world time but based on the frozen time that's locked in from MockTimeProvider, actions that pass 10 seconds apart by real-world clock time will be perceived by the SDK as having happened simultaneously if you don't call TimeTravel(double) to cover the equivalent time span in the mock time provider. (Calling TimeTravel(double) instead of TimeTravel(double, int) will move time forward without simulating any frames, which, in the case where real-world time has passed, is likely more desirable). In most cases, this desynch won't affect anything, but it is worth noting that it happens just in case a tested system depends on both the unity update loop happening and time moving forward.

Declaration
protected override bool m_EnableTimeTravel { get; }
Property Value
Type Description
bool
Overrides

Did you find this page useful? Please give it a rating: