Clean up dependencies for live / mock testing for client libraries
See original GitHub issueAt present, to enable our live / mock tests, we are using two specific versions of azure-mgmt-resources, as this particular management library provided utility classes for live/mock testing that are helpful. Depending on management libraries within the client libraries for testing feels weird, but even worse is the fact that we depend on two different versions, with one being a snapshot.
What I propose is that we isolate the set of classes we use out of azure-mgmt-resources, and add these as classes in either an azure-common-test module, or else as part of azure-common in src/test.
-
We need an
InterceptorManager
. There are two candidates (and we may bring them both in, for track two and track one, respectively): 1.1 The ‘V3’ InterceptorManager 1.2 The ‘original’ InterceptorManager -
We also require com.microsoft.azure.management.resources.core.TestBase, or an equivalent.
-
As well as com.microsoft.azure.management.resources.fluentcore.utils.ResourceManagerThrottlingInterceptor
-
We should transfer relevant test classes out of the azconfig directory into this new location.
The ideal outcome out of this would be to entirely drop out dependency on azure-mgmt-resources, and to resolve the dependency version divergence that we create.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
The main goal here is to no longer depend on azure-mgmt-resources in any of our client libraries.
Finished #1, #2, #4 For #3, currently the use case can basically be covered by reactor API(https://www.javacodegeeks.com/2017/09/testing-time-based-reactor-core-streams-virtual-time.html)
We will implement the interceptor if there is use case we need to build up more stuff on the top of the API.
Same as the ResourceManagerThrottlingInterceptor, we will add more functionalities when they are necessary in track two.
I will close the issue for now. Please feel free to reopen if any other issue to address.