Skip to content
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.

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

test(presence): Add snapshot tests for NotificationsManager #23124

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

tylerbutler
Copy link
Member

Adds a snapshot test for notifications manager that validates the following:

  • Notification messages are sent immediately
  • Notifications are sent separately (not batched - note that batching/throttling are not implemented currently so this test is more relevant for the future.

@github-actions github-actions bot added area: framework Framework is a tag for issues involving the developer framework. Eg Aqueduct dependencies Pull requests that update a dependency file base: main PRs targeted against main branch labels Nov 18, 2024
Copy link
Collaborator

@msfluid-bot msfluid-bot left a comment

Choose a reason for hiding this comment

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

Code Coverage Summary

No packages impacted by the change.


Baseline commit: dadfe49
Baseline build: 308525
Happy Coding!!

Code coverage comparison check passed!!

@msfluid-bot
Copy link
Collaborator

msfluid-bot commented Nov 18, 2024

@fluid-example/bundle-size-tests: +245 Bytes
Metric NameBaseline SizeCompare SizeSize Diff
aqueduct.js 467.24 KB 467.27 KB +35 Bytes
azureClient.js 564.01 KB 564.06 KB +49 Bytes
connectionState.js 724 Bytes 724 Bytes No change
containerRuntime.js 263.43 KB 263.45 KB +14 Bytes
fluidFramework.js 427.22 KB 427.23 KB +14 Bytes
loader.js 134.18 KB 134.19 KB +14 Bytes
map.js 42.71 KB 42.71 KB +7 Bytes
matrix.js 150.15 KB 150.16 KB +7 Bytes
odspClient.js 529.85 KB 529.89 KB +49 Bytes
odspDriver.js 97.88 KB 97.9 KB +21 Bytes
odspPrefetchSnapshot.js 42.81 KB 42.83 KB +14 Bytes
sharedString.js 166.23 KB 166.24 KB +7 Bytes
sharedTree.js 417.68 KB 417.68 KB +7 Bytes
Total Size 3.38 MB 3.38 MB +245 Bytes

Baseline commit: dadfe49

Generated by 🚫 dangerJS against bfd4912

"testEvents": {
"sessionId-2": {
"rev": 0,
"timestamp": 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

Notifications have no timestamp. Not sure that is the way it should be.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm glad you mentioned this. During debugging batching issues, I ended up running this both with and without the timestamp. It seems odd that it's not there, though I suppose we would never consider it trustworthy on a different client, too, and for the value types we have rev to address ordering. But I'm inclined to add it (separate change).

Comment on lines +33 to +38
// We are configuring the runtime to be in a connected state, so ensure it looks connected
runtime.connected = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't be needed - prepareConnectedPresence should handle that

Comment on lines 40 to 53
// Disable submitting signals with a dummy function. This ensures we don't capture signals from
// test setup, like the prepareConnectedPresence call.
const submitSignalOriginal = runtime.submitSignal;
runtime.submitSignal = () => {};

// Set up the presence connection
presence = prepareConnectedPresence(runtime, "sessionId-2", "client2", clock, logger);

// Restore the submiSignal function
runtime.submitSignal = submitSignalOriginal;
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like the other solution would be to set the snapshot version of submitSignal just at the end. Don't need a special class with any overrides.

We should look at how to share test setup across mocha and vitest if we are going to have them both.

Comment on lines 94 to 110
// Verify first signal set the newId to 77
let signal = runtime.submittedSignals[0];
expect(
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-explicit-any
(signal?.[1] as any).data["n:name:testNotificationWorkspace"].testEvents[
"sessionId-2"
].value.args,
).toEqual([77]);

// Verify first signal set the newId to 88
signal = runtime.submittedSignals[1];
expect(
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-explicit-any
(signal?.[1] as any).data["n:name:testNotificationWorkspace"].testEvents[
"sessionId-2"
].value.args,
).toEqual([88]);
Copy link
Contributor

Choose a reason for hiding this comment

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

Philosophically:
Should we have / bother with these checks of signal content when we have snapshots? (I guess probably yes and here we are basically saying these parts of the snapshot should be harder to change accidentally.)
But if we have these, how much do we care about the other nitty gritty? Are these (and maybe few others) the only value checks that should be in place? (Big snapshots are a concern for me in that when you check everything you are over-validating and make it hard to change tangential aspects. There will be a lot of noise from such tangential changes, and it can be easy to miss that something important was changed that shouldn't have been.)

NotificationsManager or any Value Manager isn't responsible for the signal really. What matters is that others receive update in the right form with the right data. The signal checks done elsewhere were because that piece (presenceDataStoreManager.ts) is the component that does the signaling. I do think that we should have some higher-order unit integration tests that check full signals, but I am not thinking that should be the most common. Perhaps we can build support for:

  1. checking that a signal has certain parts (signalsExpected array could be an object or a function array - when function we call it with the current signal content to be verified (pieces are verified)) and/or
  2. signal generated by A and processed by B yields the expected update/notification event to caller.

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot reviewed 4 out of 7 changed files in this pull request and generated 2 suggestions.

Files not reviewed (3)
  • packages/framework/presence/package.json: Language not supported
  • packages/framework/presence/src/test/snapshots/notificationsManager.vitest.js.snap: Language not supported
  • packages/framework/presence/src/test/snapshots/notificationsManager.vitest.ts.snap: Language not supported

Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more

@tylerbutler tylerbutler force-pushed the presence-notifications-shapshots branch from bfd4912 to 947dd36 Compare November 20, 2024 00:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: framework Framework is a tag for issues involving the developer framework. Eg Aqueduct base: main PRs targeted against main branch dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants