Question

The Microsoft Unit Test Wizard creates Accessor objects if you need to test a non-public property from another project. Inside my Unit Tests I create helper functions so that I don’t repeat the same code just in every Unit Test method. Currently I have two tests that are almost identical except one takes a standard public object, and the other takes the Accessor version. Since the Accessor is based on the public object I should be able to have one function. I had assumed that I could use Generics to accomplish with a simple cast. But after posting the question I discovered it was a lot more work, including having to update the underlying objects. My question is another approach to reduce these redundant methods to only having one function using casting (or another) approach?

Here are the existing two functions:

// Common function to create a new test record with standard Account object
internal static void CreateAccount(out Account account, bool saveToDatabase)
{
    DateTime created = DateTime.Now;
    string createdBy = _testUserName;

    account = new Account(created, createdBy);

    account.Notes = Utilities.RandomString(1000);

    if (saveToDatabase)
        account.Create();
}

// Common function to create a new test record with Account_Accessor
internal static void CreateAccount(out Account_Accessor account, bool saveToDatabase)
{
    DateTime created = DateTime.Now;
    string createdBy = _testUserName;

    account = new Account_Accessor(created, createdBy);

    account.Notes = Utilities.RandomString(1000);

    if (saveToDatabase)
        account.Create();
}

I have two dozen of these Unit Tests and the real objects have an average of 10 properties, I’ve simplified the examples here.

Here is the Accessor code that the Unit Test API creates (again, I have reduced it down to simplify the example):

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Collections.ObjectModel;
using System.Data;

namespace NameHere.Bll
{
    [Shadowing("NameHere.Bll.Account")]
    public class Account_Accessor : ProjectBase_Accessor<Account>
    {
        protected static PrivateType m_privateType;

        public Account_Accessor(PrivateObject value);
        [Shadowing(".ctor@2")]
        public Account_Accessor(DateTime created, string createdBy);

        [Shadowing("_notes")]
        public string _notes { get; set; }

        public static Account_Accessor AttachShadow(object value);

        [Shadowing("Create@0")]
        public override void Create();
    }
}

using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.ComponentModel;
using System.Linq.Expressions;

namespace NameHere.Bll
{
    [Shadowing("NameHere.Bll.ProjectBase`1")]
    public class ProjectBase_Accessor<T> : BaseShadow, INotifyPropertyChanged
    {
        protected static PrivateType m_privateType;

        public ProjectBase_Accessor(PrivateObject value);

        [Shadowing("Created")]
        public DateTime Created { get; set; }
        public static PrivateType ShadowedType { get; }

        [Shadowing("add_PropertyChanged@1")]
        public void add_PropertyChanged(PropertyChangedEventHandler value);
        public static ProjectBase_Accessor<T> AttachShadow(object value);

        [Shadowing("Create@0")]
        public virtual void Create();
    }
}

Answer 1

The problem is that even though the accessor class exposes the same methods and properties as the class it shadows, there is no common interface between the accessor and the original class. Account_Accessor inherits from BaseShadow, Account inherits from something else. They are completely unrelated types as far as the compiler is concerned, not assignment compatible, so it will be difficult to pass instances of each into a common routine.

If you could force the Account_Accessor class to implement an interface type that is also implemented by the Account, then you can pass instances of each to functions that take the interface type as the parameter. Like this:

internal static IAccount SetupAccount(IAccount account, bool saveToDatabase)
{
// do account setup here - not construction
}

// to call: construct instance, then pass to common function
var account = new Account(a, b);
SetupAccount(account, true);

If construction of the Account instance is complex enough that you want to have a common routine for that too, put type-specific wrappers in front of the common function:

internal static IAccount CreateAccount(bool saveToDatabase)
{
    var account = new Account(a,b);
    return SetupAccount(account, saveToDatabase);
}

internal static IAccount CreateAccountAccessor(bool saveToDatabase)
{
    var account = new Account_Accessor(a,b);
    return SetupAccount(account, saveToDatabase);
}

One point you can’t escape is this: somebody somewhere has to commit to which instance to construct. Even if you boil it down to passing types around and using Activator.CreateInstance(), somebody has to commit to selecting which type to use.

Once the instance is constructed, and both types implement a common interface, then all the common functions need to care about is the common interface.