Skip to content

NEW: Test case for monotonic timestamps. #2262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from
Open

NEW: Test case for monotonic timestamps. #2262

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
24c8585
ADD: Test case for monotonic timestamps.
ekcoh Oct 21, 2025
e8023ca
Merge branch 'develop' into add-test-case-for-monotonic-timestamps
ekcoh Oct 21, 2025
c45009c
Merge branch 'develop' into add-test-case-for-monotonic-timestamps
ekcoh Oct 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions Assets/Tests/InputSystem/CoreTests_Events.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2256,6 +2256,31 @@ public void Events_IfOldStateEventIsSentToDevice_IsIgnored()
Assert.That(gamepad.rightTrigger.ReadValue(), Is.EqualTo(0.5f).Within(0.000001));
}

[Test]
[Category("Events")]
public void Events_StateEventsAreAccepted_IfTimestampIsMonotonicAndDeviceIsKeyboard()
{
var device = InputSystem.AddDevice<Keyboard>();

InputSystem.QueueStateEvent(device, new KeyboardState(), 1.0);
InputSystem.Update();

// Accepted: equal
InputSystem.QueueStateEvent(device, new KeyboardState(Key.Space), 1.0);
InputSystem.Update();
Assert.That(device.spaceKey.ReadValue(), NUnit.Framework.Is.EqualTo(1.0f).Within(1e-6));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering why we don't use the already defined using Is = UnityEngine.TestTools.Constraints.Is that we use a lot across all codebase tests?
The same applies to other NUnit.Framework.Is.Equal calls below.

Copy link
Collaborator Author

@ekcoh ekcoh Oct 27, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will probably switch to UnityEngine.TestTools.Constraints.Is but it's just terribly annoying to have hundreds of code warnings inside the file leading to the quick navigation in scrollbar being unusable due to all warnings. The above Is extends the class I used and that generates a warning, e.g. "you should not access static functions via derived class", which makes sense. But maybe we should just add the required pragmas to the test classes to see actual warnings and fix them if this noise is removed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I create a separate PR to fix these messy using/aliasing.


// Accepted: forward
InputSystem.QueueStateEvent(device, new KeyboardState(), 1.0000001);
InputSystem.Update();
Assert.That(device.spaceKey.ReadValue(), NUnit.Framework.Is.EqualTo(0.0f).Within(1e-6));

// Discarded: backward
InputSystem.QueueStateEvent(device, new KeyboardState(Key.Space), 1.0);
InputSystem.Update();
Assert.That(device.spaceKey.ReadValue(), NUnit.Framework.Is.EqualTo(0.0f).Within(1e-6));
}

// This is another case of IInputStateCallbackReceiver making everything more complicated by deviating from
// the common, simple code path. Basically, what this test here is trying to ensure is that we can send
// touch states to a Touchscreen and not have them rejected because of timestamps. It's easy to order the
Expand Down