.NET smoke Test Sample

[JonathanCrd]

Performs functionalities with Key Vault, Identity, Event Hubs and Blob Storage Track 2 SDKs.

[danieljurek]

This is a great first cut! This review covers stylistic and a few things dealing with the general logic of the app without diving too far into program design (except the use of static). To that end we'll probably have another review where, after we get the style discussions out of the way, we can dig into the exciting details of Object Oriented design.

[weshaggard]

@JonathanCrd I'd suggest having a look at #6678 which is doing something very similar to what you are doing and so the pattern might be interesting here as well.

[pakrym]

Is the intent here to have a set of samples or to have a set of tests?

It looks like it's the later, any reason not to use unit testing framework then? What's the benefit over the live tests?

[weshaggard]

Is the intent here to have a set of samples or to have a set of tests?

The intent is actually to run a set of samples for each of the services in a single application. For now we are just writing samples independently but the goal is to eventually pull in all the samples from the library directory into this single application.

[pakrym]

The way it's written right now looks like an attempt to reinvent testing framework.

[weshaggard]

The way it's written right now looks like an attempt to reinvent testing framework.

I agree and we should definitely avoid duplicating a testing framework. I kind of like what @jsquire did in #6678 which is why I pointed to that as an example.

[pakrym]

I wonder if we can build on that idea but avoid ISample all together. Like, have every file be a self-contained copy-pastable app with Program.Main but also have a common runner that is able to run multiple samples.

[jsquire]

I wonder if we can build on that idea but avoid ISample all together. Like, have every file be a self-contained copy-pastable app with Program.Main but also have a common runner that is able to run multiple samples.

I used an interface just to enforce structure; in the context of Event Hubs, I wanted to ensure that every sample had a consistent method to execute which accepted a common set of connection parameters (to avoid ambient context and the need to set environment variables; I wanted to enable the F5 experience in Visual Studio.) I could have made implicit assumptions about the structure to avoid the interface, but preferred to make it explicit in case there were community contributions.

With respect to a generic approach that would span client libraries, I'd expect that to be tough without ending up with the need for ambient environment requirements again. In my opinion, having an approachable "it just works" experience for being able to launch the debugger is the more desirable side of that trade off.

[weshaggard]

I agree it is something to build on and I'm fine making them standalone but we still need a way to aggregate them together.

[pakrym]

With respect to a generic approach that would span client libraries, I'd expect that to be tough without ending up with the need for ambient environment requirements again. In my opinion, having an approachable "it just works" experience for being able to launch the debugger is the more desirable side of that trade off.

I wonder if we can use System.CommandLine (https://github.com/dotnet/command-line-api) inside sample apps themselves making them explicit and directly callable but also easy to aggregate.