Как получить доступ к закрытым полям статического класса для модульного тестирования его методов с помощью Microsoft Fakes в C#

Для целей UnitTesting Microsoft реализовала несколько вспомогательных классов (PrivateType и PrivateObject), которые используют отражение для подобных сценариев.

PrivateType myTypeAccessor = new PrivateType(typeof(TypeToAccess));
myTypeAccessor.SetStaticFieldOrProperty("bNoError", false);

PrivateType предназначен для статического доступа, тогда как PrivateObject вместо этого предназначен для тестирования созданных объектов.

Вам потребуется включить пространство имен Microsoft.VisualStudio.TestTools.UnitTesting из Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, чтобы использовать их.

Вы можете использовать Reflection, чтобы сделать это для целей тестирования. Хотя это совсем вне закона.

using System.Reflection;
................
................
var field = typeof(Logger).GetField("bNoError", 
                            BindingFlags.Static | 
                            BindingFlags.NonPublic);

        // Normally the first argument to "SetValue" is the instance
        // of the type but since we are mutating a static field we pass "null"
        field.SetValue(null, false);

Иногда вы можете настолько приблизиться к коду, который пытаетесь протестировать, что забываете думать об общей картине и начинаете слишком сильно сосредотачиваться на реализации. Вместо того, чтобы думать «Когда происходит XXX, ...», вы начинаете думать «Когда эта переменная установлена, ...». Когда вы дойдете до этого момента, это будет признаком того, что вы, возможно, слишком много внимания уделяете реализации и рискуете создать очень хрупкие тесты, которые сломаются, если вы что-то измените в своей реализации.

В сообщении @Martin Noreke рассказывается, как сделать то, что вы пытаетесь сделать. Однако мне кажется, что вы, возможно, тестируете не ту вещь. Похоже, что следующий тест, который вы собираетесь написать, это «Выполнить XXX с помощью Logger и проверить, что bNoError установлено на false».

Очевидно, это немного зависит от остальной части класса Logger, но кажется, что альтернативный подход может быть таким:

Call Logger method XXX, shimming dependencies if necessary in order to trigger error state.
Call Logger.Log and validate expected behaviour

Предполагая, что для bNoError есть способ вернуться к true, вы могли бы:

Call Logger method YYY, shimming dependencies if necessary to trigger error cleanup
Call Logger.Log and validate expected behaviour

Я не рекомендую использовать отражение при модульном тестировании. Сложно поддерживать большой проект с большим количеством разработчиков, потому что его нельзя легко рефакторить, найти.

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

Поэтому мое предложение сделать это публичным:

public static class Logger
{
    private bool bNoError = true;
    public static void Log()
    {
        if (!bNoError)
        {
            //Then execute the logic here
        }
        else
        {
            //else condition logic here
        }
    }

    public static bool IsAnyError()
    {
        return !bNoError;
    }
} 

Что ж, один способ — добавить метод в исходный класс, а затем скрыть его:

public static class Logger
{
    // .... other stuff here

    private static void SetbNoError(bool flag)
    {
        // leave implementation empty 
    }
}

Затем в вашем тесте:

ShimLogger.SetbNoErrorBool = flag => bNoError = flag;