Why no MoRefs in the TestHelper VMware.VimAutomation.Core?

[lucdekens]

In the testhelper module VMware.VimAutomation.Core properties that should be of type ManagedObjectReference, are defined as the actual object.
For example:

public class HostConfigManager
{
public HostDateTimeSystem DateTimeSystem { get; set; }
public ManagedObjectReference NetworkSystem { get; set; }
public HostServiceSystem ServiceSystem { get; set; }
}

Where I would expect

public class HostConfigManager
{
public ManagedObjectReference DateTimeSystem { get; set; }
public ManagedObjectReference NetworkSystem { get; set; }
public ManagedObjectReference ServiceSystem { get; set; }
}

with a new object
public class ManagedObjectReference : System.IEquatable
{
public string Type { get; set; }
public string Value { get; set; }
...

This has impact on how the Mocks are set up.

Am I missing something?

[SimeonGerginov]

Yes, for the example you have provided:

 public class HostConfigManager
 {
     public HostDateTimeSystem DateTimeSystem { get; set; }
     public ManagedObjectReference NetworkSystem { get; set; }
     public HostServiceSystem ServiceSystem { get; set; }
 }

The three types can easily be replaced with the new type you proposed. The problem I see is that the new type should have the following structure:

 public class ManagedObjectReference : System.IEquatable
 {
     public string Type { get; set; }
     public string Value { get; set; }

     public void UpdateDateTimeConfig(HostDateTimeConfig config)
     {
     }
     
     public void UpdateDnsConfig(HostDnsConfig dnsConfig)
     {
     }

     public void UpdateServicePolicy(string serviceId, string servicePolicyValue)
     {
     }
 }

So potentially this class will become very large, so we think the best solution is to have separate classes.

[lucdekens]

Why would for example the UpdateDateTimeConfig method, need to be defined on the ManagedObjectReference class?
I would expect it as a method on the HostDateTimeSystem class, just like in the vSphere API.
That would also make the mapping of the TestHelpers to the vSphere API more realistic.

[SimeonGerginov]

Sorry, I think I have misunderstood your previous example. With the Type property you can specify the type for example HostDateTimeSystem and with the Value property you will pass the value of the object ?

[lucdekens]

No, the Type and Value would behave as a regular MoRef.
You use the complete object as a value to the Get-View -Id cmdlet.
That call returns the actual object.

The reason for suggesting this, I can see code that will use this Get-View -Id format to retrieve vSphere objects.
If we implement this in the TestHelper module, I think we can actually cover that part of the code in our tests.
As an example, assume we have a Get-View -Id in a Try-Catch construct.
If the Get-View behaves as a regular Get-View when passed a MoRef, we can for example also test the Catch part (without the need to start using Throws in our mocks).

[SimeonGerginov]

Yes this will be a good solution. Do you want to work on it ?

[lucdekens]

Sure, I'll combine that with #75

[SimeonGerginov]

Ok, I am assigning you to the issue.

[SimeonGerginov]

Added to the repository via PR #82. Closing the issue.