Как правильно выполнить модульное тестирование пользовательского метода ValueResolver ResolveCore (...)

Question

Я пытаюсь выполнить модульное тестирование пользовательского ValueResolver (Automapper), но сталкиваюсь с проблемами, потому что метод, который он заставляет меня переопределить, не отображается непосредственно в пользовательском объекте, который мы должны создать.Я перезаписываю защищенный метод ResolveCore, но единственный открытый метод - Resolve, который ожидает сложный объект автоматического разрешения ResolutionResult в качестве входных данных.В духе истинного модульного тестирования я хочу протестировать этот объект / метод изолированно от всего остального и не хочу идти по пути запуска автомата с сопоставлениями для выполнения этого теста.Точно так же невозможно смоделировать «ResolutionResult» и кажется очень сложным объектом для настройки для каждого теста (опять же, требующим создания / объединения других объектов Automapper).

Единственное (не идеальное) решение, которое я могу найтис (и видел предложение, когда Googling для решения) состоит в том, чтобы заглушить открытый метод внутри класса, который предоставляет защищенный переопределенный метод.Если мы должны идти по этому пути, то пусть так и будет, но есть ли у кого-нибудь еще лучшее решение, которое проверяет вызов метода изолированно, не требует модификации объекта, который мы пытаемся проверить?

Пример кода:

public class CustomResolver : ValueResolver<Supplier, string>
{
    protected override string ResolveCore(Custom source)
    {
        return string.Format("{0} {1}", source.Name, source.Descripton);
    }

    public string UnitTestStub(Custom source)
    {
        return ResolveCore(source);
    }
}

Answer 1

Я бы не стал ставить публичную заглушку в вашем классе.Вместо этого, я просто создал бы простой подкласс в моей сборке модульного теста, который выставляет вызов, который я хотел протестировать:

public class TestCustomResolver : CustomResolver
{
    public string TestResolveCore(Custom source)
    {
        return this.ResolveCore(source);
    }
}

Отчасти это зависит от используемой вами среды модульного тестирования.Например, вы могли бы использовать атрибут InternalsVisibleTo (), чтобы представить свои внутренние компоненты вашим модульным тестам.Однако я бы склонялся к простому подклассу в ваших юнит-тестах.