Skip to content

[Iss#6180] Change TestController implementation #6651

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

vladimir-shcherbakov
Copy link
Contributor

@vladimir-shcherbakov vladimir-shcherbakov commented Jul 12, 2018

Description

Change TestController implementation.
Issue #6180

Checklist

@@ -1,6 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Microsoft.Azure.Test.HttpRecorder" version="1.8.1" targetFramework="net452" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these should come from the common targets file, shouldn't they?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the line removed

@@ -0,0 +1,45 @@
<Project Sdk="Microsoft.NET.Sdk">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commands.TestFramework, or TestFx (this is a more common abbreviation for framework)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to TestFx

[assembly: AssemblyTitle("Commands.TestFw")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("HP Inc.")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not HP :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("HP Inc.")]
[assembly: AssemblyProduct("Commands.TestFw")]
[assembly: AssemblyCopyright("Copyright © HP Inc. 2018")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not HP

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

/// Initial pair is {"Microsoft.Azure.Management.Resources.ResourceManagementClient", "2016-02-01"}
/// </param>
/// <returns>self</returns>
public IBuildable WithExtraUserAgentsToIgnore(Dictionary<string, string> userAgentsToIgnore)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHould this add to the set of ignored user agents, or replace it? The method name suggests it should add to it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the builder pattern:

  • methods that have prefix WithExtra add a specifies value to a default value;
  • methods that have prefix WithNew replace/set default value with a new one.

using Xunit;
using Xunit.Abstractions;

namespace Microsoft.Azure.Commands.Resources.Test.ScenarioTests
{
public class ResourceTests : RMTestBase
public class ResourceTests : TestManagerBuilder// : RMTestBase
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment

using Microsoft.Rest.ClientRuntime.Azure.TestFramework;
using Xunit;
using Xunit.Abstractions;

namespace Microsoft.Azure.Commands.Resources.Test.ScenarioTests
{
public class RoleAssignmentTests : RMTestBase
public class RoleAssignmentTests : TestManagerBuilder
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment

using Xunit;
using Xunit.Abstractions;

namespace Microsoft.Azure.Commands.Resources.Test.ScenarioTests
{
public class RoleDefinitionTests : RMTestBase
public class RoleDefinitionTests : TestManagerBuilder
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment

/// </summary>
/// <param name="credentials">The credentials.</param>
/// <param name="headerValues">The headers.</param>
public override HttpClientHelper CreateHttpClientHelper(SubscriptionCloudCredentials credentials, IEnumerable<ProductInfoHeaderValue> headerValues, Dictionary<string, string> cmdletHeaderValues)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just implement this in the ClientFactory, so there doesn't have to be a special implementation?

Copy link
Contributor Author

@vladimir-shcherbakov vladimir-shcherbakov Jul 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No modules, other than Resources, needed this implementation so far.

Copy link
Contributor

@praries880 praries880 Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could change in the future... As of now only one module uses it, but other modules might want to use it (if the functionality is generic enough).

If the functionality here is super tied to resource manager and we cant foresee anyone ussing this ever, then lets jsut call this class ResourceManagerTestBase.

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think thsi should be 10.0 if using the latest version of the .net test library

@markcowl markcowl removed their assignment Jul 21, 2018
<Reference Include="Microsoft.IdentityModel.Clients.ActiveDirectory">
<HintPath>..\..\packages\Microsoft.IdentityModel.Clients.ActiveDirectory.2.28.3\lib\net45\Microsoft.IdentityModel.Clients.ActiveDirectory.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="Microsoft.Rest.ClientRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Microsoft.Rest.ClientRuntime.2.3.11\lib\net452\Microsoft.Rest.ClientRuntime.dll</HintPath>
<HintPath>..\..\packages\Microsoft.Rest.ClientRuntime.2.3.7\lib\net452\Microsoft.Rest.ClientRuntime.dll</HintPath>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the version regressing here?

Copy link
Contributor Author

@vladimir-shcherbakov vladimir-shcherbakov Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This happened after I added Microsoft.Rest.ClientRuntime.Azure.TestFramework dependency to the project with NuGet.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be reverted to the newer version or is that because nuget has the older version?

Copy link
Contributor Author

@vladimir-shcherbakov vladimir-shcherbakov Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it so important? After a newer version of TestFramework release all dependencies will be updated. At the moment the 2.3.7 version of Microsoft.Rest.ClientRuntime is sufficient to get tests pass.

}

var graphClient = _mockContext.GetGraphServiceClient<GraphRbacManagementClient>();
graphClient.TenantID = context.Tenant.Id;
Copy link
Contributor

@praries880 praries880 Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does _mockContext.GetGraphServiceClient<GraphRbacManagementClient>(); not return a graphClient with the TenaniId initi'd?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I debugged this - the TenantId was not initialized, that's why I added the line #48.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it the same behavior in Playback, REcord and Live modes?
Might be better to just add a check to see if the graphClient.TenantID is non null.. in case its null only then set it to the tenentId in the context...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Context initialization happens in TestManager and depends on a test mode. I doubt mock context does any client initialization.


namespace Microsoft.Azure.Commands.Resources.Test.ScenarioTests
{
public class TestManagerBuilder
Copy link
Contributor

@praries880 praries880 Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remane this to something that implies that the class is intended to be a base class for all the resourceManager Tests?

Something like "ResourceManagerTestBase", TestManageVuilder sounds more like a builder class that should be packaged with TestManager.

Copy link
Contributor Author

@vladimir-shcherbakov vladimir-shcherbakov Jul 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@praries880,
I didn't mean TestManagerBuilder to be a base class for all the Resources module tests,

  • I would say it's just a concise way to share a common test infrastructure setup among test classes. The idea was to hide the TestManager instance initialization in the base class constructor and share it via protected member. Otherwise I had to copy the same initialization sequence to each test class constructor.
  • If a customer needs a different infrastructure setup they can build a specific version of TestManager instance and inheritance would be redundant.

Copy link
Member

@markcowl markcowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really nice work.

A few comments - I think we want to use a single pattern for consistency, I think we need to include some support for Hyak clients.


#region Hyak

public TClient CreateClient<TClient>(IAzureContext context, string endpoint) where TClient : Hyak.Common.ServiceClient<TClient>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weneed to support these, one way or another, as there are still some tests with Hyak clients. Here is a sample of how we can support these with minimal additions without having to do any elaborate mocking: https://github.com/Azure/azure-powershell/blob/preview/src/Common/Commands.ScenarioTests.Common/Mocks/MockClientFactory.cs#L111

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be implemented as part of the #6181 task.

<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Hyak.Common" version="1.1.0" targetFramework="net461" />
<package id="Microsoft.Azure.Test.HttpRecorder" version="1.8.1" targetFramework="net461" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these targets net461? just curious.


#region Builder interfaces

public interface IPreBuildable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

public interfaces should be in separate files

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I woould rename this ITestRunner and ITestRunnerFactory, to make the names closer to the functions.

{
private XunitTracingInterceptor xunitLogger;
private readonly ITestRunnable _testManager;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_testRunner. Let's use a common pattern in all the places we are using the new faclity, wither:

(1) Have all the test classes extend TestManager or
(2) Have all the test classes create an ITestRunner in their constructor.

This will make things simpler for our developers - they will have only one pattern to follow.

{
protected readonly ITestRunnable TestManager;

protected TestManagerBuilder(ITestOutputHelper output)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we shouldn't have a constructor overload that allows passing in an ITestRunnerFactory (IBuildable). This would enable tests to have their own implementation of TestManager, and still add in the default options as below.

@MiYanni
Copy link
Contributor

MiYanni commented Aug 16, 2018

Set this to Do Not Merge until we get the associated azure-powershell-common changes in.

@vladimir-shcherbakov
Copy link
Contributor Author

Evolved into the PR #7314 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants