We Keep Coding

Unit test that checks Web API 2 Controller takes forever to Request.Content.ReadAsStringAsync()

EDIT: I've added async/await keywords to no avail.
When running the following unit test,
private const string jsonRequest = #"
[
{
""productId"": ""279"",
""price"": ""20.00"",
}
]";
[TestMethod]
public async Task GivenAPostedJsonPayload_ThenCheckIfDataIsBeingSavedOnDatabase()
{
var controller = new MyBelovedController();
var message = new HttpRequestMessage();
var content = new StringContent(jsonRequest);
message.Content = content;
message.Method = HttpMethod.Post;
controller.Request = message;
var response = await controller.PostIncrementalChange();
}
with the following MyBelovedController,
[HttpPost]
public async Task<IHttpActionResult> PostIncrementalChange()
{
string jsonRequest = await Request.Content.ReadAsStringAsync(); // Debugger gets stuck here.
/* JSON deserialization and database processing take place here. */
return Ok();
}
the debugger gets stuck at the aforementioned line and takes forever to step to the next line.
Question: is there any way to make it run faster?
Specs:
My Visual Studio 2019 Professional build version is 16.8.5.
Microsoft .NET Framework version 4.8.04084.
Microsoft Windows 10 Version 2004 build version 19041.867.
EDIT: my laptop is hitting 100% CPU usage while I debug the solution, might it be the cause?

Try it this way to use async pattern. Mark your methods as async and return Task. Await the async call. Remove .Result so it is non-blocking.
[TestMethod]
public async Task GivenAPostedJsonPayload_ThenCheckIfDataIsBeingSavedOnDatabase()
{
blah, blah, blah...
var response = await controller.PostIncrementalChange();
Assert.AreEqual(System.Net.HttpStatusCode.OK, response.StatusCode);
}
[HttpPost]
public async Task PostIncrementalChange()
{
string jsonRequest = await Request.Content.ReadAsStringAsync();
}

Orchestrator function failed: The activity function failed: "Unable to resolve function name"

I have a working azure functions app where I added a sub-orchestrator with activity functions inside. The rest of the app is working just fine, but not the added code. From the logs, I can see that the sub-orchestrator is reached, but when it tries to hit the activity function, it throws the error below.
Function 'TestActivity (Orchestrator)' failed with an error. Reason: Microsoft.Azure.WebJobs.FunctionFailedException: The activity function 'GetStringInput' failed: "Unable to resolve function name 'GetStringInput'.". See the function execution logs for additional details. ---> System.InvalidOperationException: Unable to resolve function name 'GetStringInput'. at Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.FunctionInstanceLogger.d__6.MoveNext() in C:\projects\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\Diagnostics\FunctionInstanceLogger.cs:line 80
Here's the client orchestrator:
[FunctionName(FUNC_INITIALIZE)]
public static async Task<HttpResponseMessage> InitializeAsync(HttpRequestMessage req,
[OrchestrationClient(TaskHub = "%Name%")]
DurableOrchestrationClientBase client,
ILogger logger)
{
var body = new BodyObject {Something:"inside"};
var instance_id = await client.StartNewAsync(FUNC_RELEASE, body);
return req.CreateResponse(HttpStatusCode.Accepted);
}
Orchestrator:
[FunctionName(FUNC_RELEASE)]
public static async Task<string> Release(
[OrchestrationTrigger] DurableOrchestrationContextBase ctx,
ILogger log)
{
var ctx_obj = ctx.GetInput<BodyObject>();
var response = await ctx.CallSubOrchestratorAsync<int>(FUNC_ORCHESTRATE_MORE, JsonConvert.SerializeObject(ctx_json));
//do stuff with response
return new ResultObject = {Result:"response"};
}
Another Orchestrator:
[FunctionName(FUNC_ORCHESTRATE_MORE)]
public static async Task<string> OrchestrateMore(
[OrchestrationTrigger]
DurableOrchestrationContextBase ctx,
ILogger log)
{
var input = ctx.GetInput<string>();
//do stuff
var inpu_json = JsonConvert.SerilializeObject(input);
var response = await ctx.CallActivityAsync<int>(FUNC_ACTIVITY, input_json);
//do stuff with response
return JsonConvert.SerializeObject(new ResultObject = {Result:"response"});
}
Activity
[FunctionName(FUNC_ACTIVITY)]
public static async Task<string> DoingActivity(
[ActivityTrigger] string input,
ILogger log)
{
//do stuff with input
return string_of_info;
}
From the portal, I can see that the activity functions exist and are enabled. Changing the signature of the activity functions to use the type DurableActivityContext yielded the same results. Submitting the request from inside the portal itself yielded a 404 not found error only on the activities added, not on existing activities.
Other info:
.NET 472,
Microsoft.Azure.WebJobs v2.3.0,
Microsoft.Azure.WebJobs.Http v1.2.0,
Microsoft.Azure.WebJobs.Extensions.DurableTask v1.8.4
Microsoft.Azure.WebJobs.ServiceBus v2.2.0
Microsoft.NET.Sdk.Functions v1.0.29
App is being deployed through Azure DevOps.
Any help would be much appreciated!

GetAsync azure call no result

Using VS 2017 Community. Azure.
I have Azure setup, I have a blank webapp created just for test purpose.
My actual site is an Angular2 MVC5 site, currently run locally.
The following is the code that should... Contact azure providing secret key(the site is registered in azure Active directory).
From this i get a token i then can use to contact azure api and get list of sites.
WARNING: code is all Sausage code/prototype.
Controller
public ActionResult Index()
{
try
{
MainAsync().ConfigureAwait(false);
}
catch (Exception e)
{
Console.WriteLine(e.GetBaseException().Message);
}
return View();
}
static async System.Threading.Tasks.Task MainAsync()
{
string tenantId = ConfigurationManager.AppSettings["AzureTenantId"];
string clientId = ConfigurationManager.AppSettings["AzureClientId"];
string clientSecret = ConfigurationManager.AppSettings["AzureClientSecret"];
string token = await AuthenticationHelpers.AcquireTokenBySPN(tenantId, clientId, clientSecret).ConfigureAwait(false);
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Add("Authorization", "Bearer " + token);
client.BaseAddress = new Uri("https://management.azure.com/");
await MakeARMRequests(client);
}
}
static async System.Threading.Tasks.Task MakeARMRequests(HttpClient client)
{
const string ResourceGroup = "ProtoTSresGrp1";
// Create the resource group
// List the Web Apps and their host names
using (var response = await client.GetAsync(
$"/subscriptions/{Subscription}/resourceGroups/{ResourceGroup}/providers/Microsoft.Web/sites?api-version=2015-08-01"))
{
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsAsync<dynamic>().ConfigureAwait(false);
foreach (var app in json.value)
{
Console.WriteLine(app.name);
foreach (var hostname in app.properties.enabledHostNames)
{
Console.WriteLine(" " + hostname);
}
}
}
}
Controller class uses a static helper class that gets the token from Azure...
public static class AuthenticationHelpers
{
const string ARMResource = "https://management.core.windows.net/";
const string TokenEndpoint = "https://login.windows.net/{0}/oauth2/token";
const string SPNPayload = "resource={0}&client_id={1}&grant_type=client_credentials&client_secret={2}";
public static async Task<string> AcquireTokenBySPN(string tenantId, string clientId, string clientSecret)
{
var payload = String.Format(SPNPayload,
WebUtility.UrlEncode(ARMResource),
WebUtility.UrlEncode(clientId),
WebUtility.UrlEncode(clientSecret));
var body = await HttpPost(tenantId, payload).ConfigureAwait(false);
return body.access_token;
}
static async Task<dynamic> HttpPost(string tenantId, string payload)
{
using (var client = new HttpClient())
{
var address = String.Format(TokenEndpoint, tenantId);
var content = new StringContent(payload, Encoding.UTF8, "application/x-www-form-urlencoded");
using (var response = await client.PostAsync(address, content).ConfigureAwait(false))
{
if (!response.IsSuccessStatusCode)
{
Console.WriteLine("Status: {0}", response.StatusCode);
Console.WriteLine("Content: {0}", await response.Content.ReadAsStringAsync());
}
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsAsync<dynamic>().ConfigureAwait(false);
}
}
}
}
ISSUE:
Ok so the issue I was faced with was Async Deadlocks in my code. So i looked at this stack post stack post here
I fixed the issues by putting in .ConfigureAwait(false) on most of the await declarations.
Code runs and gets all the way back to the controller with a token etc and runs through the MakeARMRequests(HttpClient client) method, however the json only returns 1 result "{[]}" when i debug and as such ignores the loops.
My question is, is my code the culprit here? or would this point to a configuration setting in azure?

Not sure if this is the issue you are facing now BUT you never wait for a result from your async action in the first method Index in your code. MainAsync().ConfigureAwait(false); will immediately return and continue to the next block while the task MainAsync() will start in the background. The catch handler also does nothing because you dont wait f or a result.
Option 1 (recommended)
public async Task<ActionResult> Index()
{
try
{
await MainAsync().ConfigureAwait(false);
}
catch (Exception e)
{
Console.WriteLine(e.GetBaseException().Message);
}
return View();
}
Option 2 if you can't use async/await for some reason
public ActionResult Index()
{
try
{
MainAsync().GetAwaiter().GetResult();
}
catch (Exception e)
{
Console.WriteLine(e.GetBaseException().Message);
}
return View();
}

The Code looks OK and runs fine, Anyone who could help verify would be good, but one can assume this is OK.
The issue for this was configuration in azure, When you register an app you must set a certain number of Access controls via the subscription.
In this case I set some more specific things for the web api , for now set the app as owner and made reference to service management api.
Probably don't need half the "IAM" added in the subscription to the registered app, I simply went through adding the relevant ones and debugging each time until finally i got the results expected.

HttpClient PostAsync not working in CRM plugin

I am trying to send json to a web API using HttpClient.PostAsync. It works from a console application but not from my CRM plugin. Doing some research I noted that it is probably something to do with the context the plugin runs in and threading. Anyway here is my calling code:
public async void Execute(IServiceProvider serviceProvider)
{
IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
if (context.InputParameters.Contains("Target"))
{
if (context.InputParameters["Target"] is Entity)
{
Entity entity = (Entity)context.InputParameters["Target"];
if (entity.LogicalName == "new_product")
{
IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);
try
{
if (entity.Contains("new_begindate") && entity.Contains("new_expirationdate"))
{
await OnlineSignUp(entity, service);
}
}
catch (InvalidPluginExecutionException)
{
throw;
}
catch (Exception e)
{
throw new InvalidPluginExecutionException(OperationStatus.Failed, "Error signing up: " + e.Message);
}
}
}
}
}
And here is the relevant code for sending the json:
private async Task<HttpResponseMessage> OnlineSignUp(Entity license, IOrganizationService service)
{
...
var json = JsonConvert.Serialize(invitation);
var content = new StringContent(json, Encoding.UTF8, "application/json");
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Token", "token=7d20f3f09ef24067ae64f4323bc95163");
Uri uri = new Uri("http://signup.com/api/v1/user_invitations");
var response = await httpClient.PostAsync(uri, content).ConfigureAwait(false);
int n = 1;
return response;
}
}
The exception is thrown with a message "Thread was being aborted". Can anyone tell me what I am doing wrong?

I would guess this is going to fail somewhat randomly based on use of async/await. I wouldn't think CRM really supports plugins returning control before they are complete. When it fails, it looks like the thread was in the process of being cleaned up behind the scenes.
CRM is already handling multi-threading of plugins and supports registering plugin steps as asynchronous if they are long running (or don't need to be run in the synchronous pipeline). It would make more sense to use a synchronous HTTP call here like:
var response = httpClient.PostAsync(uri, content).Result;
EDIT: To illustrate, this is an overly-trivialized example of what is most likely happening when CRM goes to kickoff your plugin and you're using async/await (from LinqPad).
static async void CrmInternalFunctionThatKicksOffPlugins()
{
var plugin = new YourPlugin();
//NOTE Crm is not going to "await" your plugin execute method here
plugin.Execute();
"CRM is Done".Dump();
}
public class YourPlugin
{
public async void Execute()
{
await OnlineSignUp();
}
private async Task<HttpResponseMessage> OnlineSignUp()
{
var httpClient = new HttpClient();
var r = await httpClient.PostAsync("http://www.example.com", null);
"My Async Finished".Dump();
return r;
}
}
Which will print:
CRM is Done My Async Finished

looks like you are using Json.NET, when you use external assemblies there are some things to take care of (merging) and not always the result works.
Try to serialize using DataContractJsonSerializer
example: http://www.crmanswers.net/2015/02/json-and-crm-sandbox-plugins.html

What should a controller integration test assert

Doing an integration test on a web api endpoint what should I put my focus on to assert?
My endpoint is also doing a call to a domain service.
Should I mock that service? With the current code that is not possible, because I would need to instantiate the controller to pass the mock service.
Am I interested in the service return value? actually not.
I am only interested wether the endpoint was succesfully triggered but then I should isolate the service call I guess.
Any advice is welcome :-)
TEST
[TestClass]
public class SchoolyearControllerTests
{
private TestServer _server;
[TestInitialize]
public void FixtureInit()
{
_server = TestServer.Create<Startup>();
}
[TestCleanup]
public void FixtureDispose()
{
_server.Dispose();
}
[TestMethod]
public void Get()
{
var response = _server.HttpClient.GetAsync(_server.BaseAddress + "/api/schoolyears").Result;
var result = response.Content.ReadAsAsync<IEnumerable<SchoolyearDTO>>().GetAwaiter().GetResult();
Assert.AreEqual(response.StatusCode, HttpStatusCode.OK);
}
}
Action to test
[HttpGet]
public async Task<IHttpActionResult> Get()
{
var schoolyears = await service.GetSchoolyears();
return Ok(schoolyears);
}

The trouble with doing an integration test on a web service is that it doesn't tell you very much about the problem - or even if there actually is one, and if there is, it doesn't tell you where the issue lies. It will either succeed or fail. So in that respect did you get a 200 response code or a 500 response code... but did it fail because:
The server was unreachable
The web service isn't started, or failed when trying to start
A firewall is blocking the network
A database record wasn't found
There's a database schema problem and entity framework didn't start
properly.
It could literally be anything - and result might be different on your dev machine than in production - so what does it really tell you about your application?
What makes for robust software is to test that your product is able to handle any of these situations correctly, gracefully and robustly.
I write my controller actions like this:
public HttpResponseMessage Get(int id)
{
try
{
var person = _personRepository.GetById(id);
var dto = Mapper.Map<PersonDto>(person);
HttpResponseMessage response = Request.CreateResponse<PersonDto>(HttpStatusCode.OK, dto);
return response;
}
catch (TextFileDataSourceException ex)
{
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.InternalServerError);
return response;
}
catch (DataResourceNotFoundException ex)
{
HttpResponseMessage response = Request.CreateErrorResponse(HttpStatusCode.NotFound, ex);
return response;
}
catch (FormatException ex)
{
HttpResponseMessage response = Request.CreateErrorResponse(HttpStatusCode.InternalServerError, ex);
return response;
}
catch (Exception ex)
{
HttpResponseMessage response = Request.CreateErrorResponse(HttpStatusCode.InternalServerError, ex);
return response;
}
}
A try block gets the data, makes a dto and returns the data with a 200 code. There are several error conditions handled here, but none indicate a problem with my web service itself and some (404 error) don't even indicate an issue with the application - I EXPECT a NotFoundException and a 404 if my application can't find a record - if this happens my application WORKS in this scenario.
So if any of these error conditions occur, its not because there's a problem with the web service, and not necessarily a problem with the app. But I can test that my web service is returning the correct response for any of these expected conditions.
The tests for this controller action looks like this:
[Test]
public void CanGetPerson()
{
#region Arrange
var person = new Person
{
Id = 1,
FamilyName = "Rooney",
GivenName = "Wayne",
MiddleNames = "Mark",
DateOfBirth = new DateTime(1985, 10, 24),
DateOfDeath = null,
PlaceOfBirth = "Liverpool",
Height = 1.76m,
TwitterId = "#WayneRooney"
};
Mapper.CreateMap<Person, PersonDto>();
var mockPersonRepository = new Mock<IPersonRepository>();
mockPersonRepository.Setup(x => x.GetById(1)).Returns(person);
var controller = new PersonController(mockPersonRepository.Object);
controller.Request = new HttpRequestMessage(HttpMethod.Get, "1");
controller.Configuration = new HttpConfiguration(new HttpRouteCollection());
#endregion
#region act
HttpResponseMessage result = controller.Get(1);
#endregion
#region assert
Assert.AreEqual(HttpStatusCode.OK, result.StatusCode);
#endregion
}
[Test]
public void CanHandlePersonNotExists()
{
#region Arrange
var mockPersonRepository = new Mock<IPersonRepository>();
mockPersonRepository.Setup(x => x.GetById(1)).Throws<DataResourceNotFoundException>();
var controller = new PersonController(mockPersonRepository.Object)
{
Request = new HttpRequestMessage(HttpMethod.Get, "1"),
Configuration = new HttpConfiguration(new HttpRouteCollection())
};
#endregion
#region Act
HttpResponseMessage result = controller.Get(1);
#endregion
#region Assert
Assert.AreEqual(HttpStatusCode.NotFound, result.StatusCode);
#endregion
}
[Test]
public void CanHandleServerError()
{
#region Arrange
var mockPersonRepository = new Mock<IPersonRepository>();
mockPersonRepository.Setup(x => x.GetById(1)).Throws<Exception>();
var controller = new PersonController(mockPersonRepository.Object);
controller.Request = new HttpRequestMessage(HttpMethod.Get, "1");
controller.Configuration = new HttpConfiguration(new HttpRouteCollection());
#endregion
#region Act
HttpResponseMessage result = controller.Get(1);
#endregion
#region Assert
Assert.AreEqual(HttpStatusCode.InternalServerError, result.StatusCode);
#endregion
}
Note that I'm introducing a mock respository and having my mock repository trigger the expected exceptions for 404 and server error and ensuring that the web service handles it correctly.
What this tells me is that my web service handling expected and exceptional situations as it should and returning the appropriate codes: 200/404/500.
Although some are error states and some are success states, none of these outcomes indicate a problem with my web service - it is behaving exactly as it should, and that's what I want to test.
An 'across the network' integration test on a web service tells you nothing about the robustness or correctness of your application - or even if its returning the correct data or response-code.
Don't try to re-test WebAPI... Microsoft wrote a massive suite of tests for it already - hundreds of test-fixture classes, thousands of test methods:
https://aspnetwebstack.codeplex.com/SourceControl/latest#test/System.Web.Http.Test/Controllers/ApiControllerTest.cs
Assume that WebAPI works as it should and doesn't require you to test it again. Focus on testing your application code and make sure success and error conditions are handled gracefully by your web service.
If you want to check your web service is connected and available on the network - open a browser and test it manually; there's no need to automate this; the result will vary between environments and according to external conditions.
Test each layer of your application the same way, mock out the layer above and test that the current layer handles every possible outcome from the layer above.
Your client application for your service should do the same thing: Mock the web service, and pretend that it gave a 404 - and check that it handles this as it should.