Class DeferredMessagingTest
Inherited Members
Namespace: Unity.Netcode.RuntimeTests
Assembly: solution.dll
Syntax
public class DeferredMessagingTest : NetcodeIntegrationTestProperties
| Name | Description |
|---|---|
| NumberOfClients | |
| 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:
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. |
| m_SetupIsACoroutine | If this is false, SetUp will call OnInlineSetUp instead of OnSetUp. This is a performance advantage when not using the coroutine functionality, as a coroutine that has no yield instructions in it will nonetheless still result in delaying the continuation of the method that called it for a full frame after it returns. |
| m_TearDownIsACoroutine | If this is false, TearDown will call OnInlineTearDown instead of OnTearDown. This is a performance advantage when not using the coroutine functionality, as a coroutine that has no yield instructions in it will nonetheless still result in delaying the continuation of the method that called it for a full frame after it returns. |