-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Add "arguments" deserialization tests for "script.callFunction" #34830
Add "arguments" deserialization tests for "script.callFunction" #34830
Conversation
Looks perfect to me! |
) | ||
async def test_primitive_values(bidi_session, top_context, argument): | ||
result = await bidi_session.script.call_function( | ||
function_declaration=f"(arg) => arg", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the problem here is that we actually do not compare the result of the deserialization but a complete round trip including deserialization and serialization. In case of the serialization also be broken we wouldn't detect a failure for the deserialization.
As such we would need an assertion for a type check as part of the function declaration. If that passes the value also needs to be checked. Then the test will pass if no exceptionDetails
are part of the return value for the script.callFunction
call.
The same actually also applies to the other test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sadym-chromium fyi whimboo is off for a few weeks, but I agree with his feedback here. Ideally this should only assert deserialization. I received a ping for this review today but I didn't see a new patch. I'm assuming the ping was sent before seeing the comment above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I pinged before I saw the comment.
Ideally, we want to test only deserialization, but comparing sets, arrays, maps and objects on the backend is quite messy. So having we tested serialization, I guess it's acceptable trade-off just to check the types of non-pimitives on the server side, and check the "deserialized-serialized" values on the client side. I implemented this approach in the current revision. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update Maksim! The compromise sounds fine, but asserting arrays, maps, sets (...) in JS would not make the test that hard to follow IMO. Back to you for a few comments, I'll take one last look with those addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
target=ContextTarget(top_context["context"]), | ||
) | ||
|
||
assert result == nan_remote_value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use recursive compare here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense. Done
According to @juliandescottes, @whimboo is off for a few weeks
script.callFunction