You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all, I was attempting to rebase PR #12 on top of the latest changes and ran into an interesting problem. A unit test was written for the EvenGridTriggerBinding::BindAsync method here:
Assert.Equal($"Unable to bind {testObject} to type {arrayParam[0].ParameterType}", invalidException.Message);
}
This unit test now passes in two totally different types of source values which the "old" EventGridTriggerBinding did support. They are string and EventGridEvent.
The question I have is: why does this binding need to support more than one? The binding itself is an internal class that closely cooperates with EventGridExtensionConfig's IAsyncConverter<HttpRequestMessage, HttpResponseMessage> whose responsibility it is to provide the value into the binding... albeit indirectly. Seen here:
In the current implementation, the EventGridExtensionConfig is always translating the incoming HttpRequestMessage body from JSON into a strongly typed List<EventGridEvent> and then triggering the functions with the individual EventGridEvent instances. Given that, the binding will never see string parameter.
So, that said, while the binding implementation supports converting the raw value from a string, it will never have to do that AFAICT and, therefore, the unit test that was added covers a scenario that doesn't really exist and should thus be removed. Additionally I would suggest that the test method is extremely overloaded with way too many responsibilities and should be refactored into multiple tests.
The text was updated successfully, but these errors were encountered:
In PR #12 I'm going to go ahead and refactor this test to work against my implementation. I'll push an update to the PR with those changes and await any other feedback the team might have to offer.
...I should track better of the issues
The answer lies in b6af0df
in short, there is more than 1 way to call bindAsync, one of which is through admin/functions/{name} api which allows user to pass the function argument in HTTP request body, function runtime will first parse it to string and then invoke user function (reference)
How about the cloudevent schema? i dont see that in the code currently. I see documentation stating that i could just use CloudEvent but the validation fails because there is nothing in there for cloud events?
Hi all, I was attempting to rebase PR #12 on top of the latest changes and ran into an interesting problem. A unit test was written for the EvenGridTriggerBinding::BindAsync method here:
azure-functions-eventgrid-extension/test/Extension.tests/UnitTests.cs
Lines 20 to 44 in 9a9b3ee
This unit test now passes in two totally different types of source values which the "old"
EventGridTriggerBinding
did support. They arestring
andEventGridEvent
.The question I have is: why does this binding need to support more than one? The binding itself is an internal class that closely cooperates with
EventGridExtensionConfig
'sIAsyncConverter<HttpRequestMessage, HttpResponseMessage>
whose responsibility it is to provide the value into the binding... albeit indirectly. Seen here:azure-functions-eventgrid-extension/src/EventGridExtension/EventGridExtensionConfig.cs
Lines 85 to 96 in 9a9b3ee
In the current implementation, the
EventGridExtensionConfig
is always translating the incomingHttpRequestMessage
body from JSON into a strongly typedList<EventGridEvent>
and then triggering the functions with the individualEventGridEvent
instances. Given that, the binding will never seestring
parameter.So, that said, while the binding implementation supports converting the raw value from a
string
, it will never have to do that AFAICT and, therefore, the unit test that was added covers a scenario that doesn't really exist and should thus be removed. Additionally I would suggest that the test method is extremely overloaded with way too many responsibilities and should be refactored into multiple tests.The text was updated successfully, but these errors were encountered: