Skip to content

A place to put some locally-developed exercise code for Azure training, from the module [Create serverless applications](https://docs.microsoft.com/en-us/learn/paths/create-serverless-applications/)

License

Notifications You must be signed in to change notification settings

rdalkire/DavesAzureSourceCode

Repository files navigation

Azure Functions and Testing

I started this because code created as part of Exercise - Unit test an Azure Function is not "future-proofed" with dotnet core 3.1, because by then, Microsoft stopped supporting public-yet-internal, or "pubternal" APIs. The problematic item specifically for this case is Microsoft.AspNetCore.Http.Internal.DefaultHttpRequest. See ..."Pubternal" APIs removed

To move to a more modern method, I attempted to use guidance from the article Integration tests in ASP.NET Core, hoping to use utilities found in Microsoft.AspNetCore.Mvc.Testing to test azure functions. So far this does not bear fruit - See WatchFunction.IntegrationTests - at the time of this edit, the latest test failure is "System.InvalidOperationException : Having multiple overloads of method 'Configure' is not supported."

However I find that there's another way to avoid the use of that 'Http.Internal namespace. Consider these lines:

using Microsoft.AspNetCore.Http;

// ...
// class and method definitions...
// ...

	var req = new Microsoft.AspNetCore.Http.Internal.
		DefaultHttpRequest( new DefaultHttpContext() );

Simply change how you're getting that request like so:

using Microsoft.AspNetCore.Http;

// ...
// class and method definitions...
// ...

	var req = new DefaultHttpContext().Request;

That's it! No more dependence on things that were not intended for your use in the first place.

But I still wanted to use dependency injection to support integration testing, so I turned to a blog article Integration Testing in Azure Functions with Dependency Injection, by Saeb Amini, and his example/template Github project Saeb.FunctionApp. You can see the way I adopted his work in my test class WatchFunction.TestsFromExercise.WatchFunctionIntegrationTestLikeSaebs and the dependent classes, which are copies from his "Infrastructure" directory.

One change I made in there was to fill in some implementation for his ReplaceTestOverrides, to demonstrate how in integration testing, one sometimes "stubs" the domain functionality. This is in contrast to unit testing, where one "stubs" the infrastructure code.

    private void ReplaceTestOverrides(IServiceCollection services)
    {
        services.Replace(new ServiceDescriptor(typeof(IWatchInfoProvider), new TestWatchInfoProvider()));
    }

About

A place to put some locally-developed exercise code for Azure training, from the module [Create serverless applications](https://docs.microsoft.com/en-us/learn/paths/create-serverless-applications/)

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages