Using Application Insights with Unit Tests?

Question

I have an MVC web app, and I'm using Simple Injector for DI. Almost all my code is covered by unit tests. However, now that I've added some telemetry calls in some controllers, I'm having trouble setting up the dependencies.

The telemetry calls are for sending metrics to the Microsoft Azure-hosted Application Insights service. The app is not running in Azure, just a server with ISS. The AI portal tells you all kinds of things about your application, including any custom events you send using the telemetry library. As a result, the controller requires an instance of Microsoft.ApplicationInsights.TelemetryClient, which has no Interface and is a sealed class, with 2 constructors. I tried registering it like so (the hybrid lifestyle is unrelated to this question, I just included it for completeness):

// hybrid lifestyle that gives precedence to web api request scope var requestOrTransientLifestyle = Lifestyle.CreateHybrid(     () => HttpContext.Current != null,     new WebRequestLifestyle(),     Lifestyle.Transient);  container.Register<TelemetryClient>(requestOrTransientLifestyle); 

The problem is that since TelemetryClient has 2 constructors, SI complains and fails validation. I found a post showing how to override the container's constructor resolution behavior, but that seems pretty complicated. First I wanted to back up and ask this question:

If I don't make the TelemetryClient an injected dependency (just create a New one in the class), will that telemetry get sent to Azure on every run of the unit test, creating lots of false data? Or is Application Insights smart enough to know it is running in a unit test, and not send the data?

Any "Insights" into this issue would be much appreciated!

Thanks

Answer 1

Application Insights has an example of unit testing the TelemetryClient by mocking TelemetryChannel.

TelemetryChannel implements ITelemetryChannel so is pretty easy to mock and inject. In this example you can log messages, and then collect them later from Items for assertions.

public class MockTelemetryChannel : ITelemetryChannel {     public IList<ITelemetry> Items     {         get;         private set;     }      ...      public void Send(ITelemetry item)     {         Items.Add(item);     } }  ...  MockTelemetryChannel = new MockTelemetryChannel();  TelemetryConfiguration configuration = new TelemetryConfiguration {     TelemetryChannel = MockTelemetryChannel,     InstrumentationKey = Guid.NewGuid().ToString() }; configuration.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());  TelemetryClient telemetryClient = new TelemetryClient(configuration);  container.Register<TelemetryClient>(telemetryClient); 

Answer 2

Microsoft.ApplicationInsights.TelemetryClient, which has no Interface and is a sealed class, with 2 constructors.

This TelemetryClient is a framework type and framework types should not be auto-wired by your container.

I found a post showing how to override the container's constructor resolution behavior, but that seems pretty complicated.

Yep, this complexity is deliberate, because we want to discourage people from creating components with multiple constructors, because this is an anti-pattern.

Instead of using auto-wiring, you can, as @qujck already pointed out, simply make the following registration:

container.Register<TelemetryClient>(() =>      new TelemetryClient(/*whatever values you need*/),     requestOrTransientLifestyle); 

Or is Application Insights smart enough to know it is running in a unit test, and not send the data?

Very unlikely. If you want to test the class that depends on this TelemetryClient, you better use a fake implementation instead, to prevent your unit test to either become fragile, slow, or to pollute your Insight data. But even if testing isn't a concern, according to the Dependency Inversion Principle you should depend on (1) abstractions that are (2) defined by your own application. You fail both points when using the TelemetryClient.

What you should do instead is define one (or perhaps even multiple) abstractions over the TelemetryClient that are especially tailored for your application. So don't try to mimic the TelemetryClient's API with its possible 100 methods, but only define methods on the interface that your controller actually uses, and make them as simple as possible so you can make both the controller's code simpler -and- your unit tests simpler.

After you defined a good abstraction, you can create an adapter implementation that uses the TelemetryClient internally. I image you register this adapter as follows:

container.RegisterSingleton<ITelemetryLogger>(     new TelemetryClientAdapter(new TelemetryClient(...))); 

Here I assume that the TelemetryClient is thread-safe and can work as a singleton. Otherwise, you can do something like this:

container.RegisterSingleton<ITelemetryLogger>(     new TelemetryClientAdapter(() => new TelemetryClient(...))); 

Here the adapter is still a singleton, but is provided with a delegate that allows creation of the TelemetryClient. Another option is to let the adapter create (and perhaps dispose) the TelemetryClient internally. That would perhaps make the registration even simpler:

container.RegisterSingleton<ITelemetryLogger>(new TelemetryClientAdapter());