-
Notifications
You must be signed in to change notification settings - Fork 8
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
Troubles stubbing a URL with complex query parameters, i.e. has "{" and "}" in URL #16
Comments
hello ! QueryString parameters don't generally have curly braces, they are generally look like ?Age=35&Name=Tony If heades is what you need, there is a parameter for that in AppendHttpCallStub for such scenarios (https://github.com/AlanCS/SystemTestingTools/blob/master/Tool/SystemTestingTools/Extensions/HttpClientExtensions.cs#L54) If you absolutely must send a query string param with curly braces, maybe formatting it with https://learn.microsoft.com/en-us/dotnet/api/system.web.httputility.urlencode?view=net-8.0#system-web-httputility-urlencode(system-string) would solve your problem if the solutions above don't work, could you please raise a PR with a failing test containing your problem ? This package is also tested using component testing, and this is the perfect situation to create a test for such "wiring" edge case :) you can add a new method in an existing or new controller in https://github.com/AlanCS/SystemTestingTools/tree/master/Examples/MovieProject/MovieProject.Web/Controllers, showcasing the complex parameters you are using and then add a failing test https://github.com/AlanCS/SystemTestingTools/tree/master/Examples/MovieProject/MovieProject.Tests/MovieProject.IsolatedTests/ComponentTesting that will highlight your problem I hope this helps, let me know how it goes one way or another ! |
Hey Alan, Thank you very much for your reply. Yeah it's unfortunate that the endpoint that we need to integrate with expects complex query parameters like the example described, but alas it has to be done. I will try to raise a PR within the week to add a failing test. |
Hello ! the latest build has fixed the problem I had to make some adjustments to your test, as the problem you described was about sending a querystring parameter with brackets let me know if it makes sense, or if you have other problems PS: I am having a bit of difficulty publishing the new nuget package, as the pipeline mechanism in github changed a lot since I last worked on it, it no longer works. I am focusing on fixing it now, should be available to you in the next few days at worst |
Hey Alan, Thanks for addressing this issue! However, I think the test case did suit my use case, where we require passing the query string parameter with brackets to the proxy. As a result, I tried to pass the URL + query string to I agree that it makes the identification of the downstream call quite difficult. How would you recommend stubbing the proxy if it expects complex query parameters? (Guessing that as long as I get the syntax exactly the same as the downstream's call, it should be fine, so maybe I should use System.Text.Json to serialise the class?) PS: Thanks again for fixing this and your responsiveness, a few days' wait will be totally fine! |
Sorry for the delay, the build pipeline was very out of date, took me a while to fix it up ! about you particular problem, I think I visualize it now
private readonly IHttpContextAccessor accessor;
public CarController(IHttpContextAccessor accessor)
{
this.accessor = accessor;
}
[HttpGet]
public async Task<List<Car>> DoSomething() // many query string parameters here, but you don't need to catch as inputs to this method
{
string querystring = this.accessor.HttpContext.Request.QueryString;
return await _carService.Foward(querystring);
}
you could check for something in the beginning and the middle" client.GetSessionOutgoingRequests()[0].GetEndpoint().Should().StartWith("GET http://www.mydoing.com/myapi?myfield={{").And.Contains("Bret"); if you need to check the whole URL, you could also try to remove all whitespace and lower case the whole string, to make sure that different serialization methods would still return the same result Let me know if it makes sense |
Hey Alan, Again, thanks for the fix. I could use the new package version to stub the legacy proxy endpoint call that was causing us much trouble. My team is using this for a couple of component/ acceptance testing projects to ensure that the endpoints are invoked with My solution was to carefully craft the URL to be fed into
Then when invoking the proxy within the service, I would serialise the object with the same options listed above, with no encoding done. That allowed me to create an exact matching stub for the call required. |
I am using SystemTestingTools Version 2.0.32. I am using the
AppendHttpCallStub
to set up my stub for the endpoint that I'm writing tests for. I am aware that when I feed in a URI into the said method, I need to escape the curly brackets by doubling them up. Not escaping them will cause an exception to be thrown in the methodSetEndpoint
asString.Format
will throw aFormatException
error. However, escaping before callingAppendHttpCallStub
does not suffice. Later when the stubbed endpoint is called. The GetEndpoint method is invoked, and since the the previousString.Format
call inSetEndpoint
removes the escaped characters, theString.Format
in this method is thrown.Any advise on how to get around this is deeply appreciated!
The text was updated successfully, but these errors were encountered: