Event Hubs test scopes should detect environment variables

Summary

The live tests within the Event Hubs client library will dynamically manage their Azure resource needs for a run, creating and removing items to fulfill test needs. This includes the Event Hubs namespace that the tests use, as well as the individual Event Hub and consumer group instances beneath them.

For quicker developer iteration in limited scenarios that do not require a full run, it is desirable to allow an existing set of Azure resources to be specified.

Scope of Work

• If the EventHubScope detects an environment variable EVENT_HUBS_NAMESPACE_CONNECTION_STRING, then it should not create a new namespace and should return that connection string as the instance for the test run. In this scenario, the scope should remove any entity reference to an Event Hub and scope the connection string to the namespace only.

• If the EventHubScope detects an environment variable EVENT_HUBS_EVENT_HUB_NAME, then it should not create a new event hub for each test scope and should, instead, return the specified Event Hub name. In this scenario, the scope should use the management library to query the available consumer groups for the specified Event Hub and return those as part of the scope.

• If the StorageScope (EventProcessorStore.Blobs package) detects an environment variable EVENT_HUBS_BLOBS_CONNECTION_STRING, then it should not create a new storage account and, instead, that connection string as the instance for the test run.

• Tests have been added or adjusted to cover the enhancements and ensure their functionality.

Out of Scope

• Handling of any other environment variables.

• Attempting to notify or influence tests that they’re using an existing and potentially shared resource; it is responsibility of the developer providing the environment variables to ensure the test(s) being run against it are tolerant of a “used” and shared resource.

Success Criteria

• The refactoring and enhancements detailed by the scope have been completed.

• The tests necessary for its validation have been created or adjusted and pass reliably.

• The existing test suite continues to produce deterministic results and pass reliably.

[jsquire]

the project reference will cause issues because we also reference that as a package transiently through the CheckpointStore.Blobs reference

That would prompt me to ask you if we should not check-in the InternalsVisibleTo now, in order to have it ready for when Azure.Messaging.EventHubs (5.0.0-preview.6) will be out?

I’m thinking we probably should strongly consider just writing a simple parser and accept a bit of code duplication to avoid the additional complexity in the referencing. It feels like quite a bit of heavy changes to avoid duplicating a very small and specialized bit of code. Thoughts? Am I overlooking some additional benefits?

[albertodenatale]

Thoughts? Am I overlooking some additional benefits?

That’s what I call critical thinking!

I love how you broke down the problem, complexity vs duplication.

The only major issue I could see is if there was a bug fix and we forgot to take it in the copied version, but it would become visible quite quickly being this a testing environment.

The Shared folder limits the number of copies to two.

If we added in future a copy of something else, we might still be in time to add a reference.

I absolutely love it, let’s go for it.