Как писать модульные тесты для частных методов

Вы хотите иметь возможность вызвать свой частный метод в тесте и посмотреть, как он работает?

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

Изменить: поскольку этот ответ все еще привлекает некоторый трафик, я делюсь этой ссылкой. Это сообщение в блоге было создано примерно через 4 года после того, как я опубликовал свой ответ: https://enterprisecraftsmanship.com/posts/unit-testing-private-methods/.

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

Возможно, у вас есть возможность реорганизовать код, чтобы частные методы стали общедоступными методами какого-то другого класса (ов). Хорошим примером является класс, который планирует некоторую работу по таймеру для обработки в более позднее время. Метод работы, вероятно, будет реализован как частный метод, что затруднит тестирование простым способом без планирования таймера и ожидания, пока он выполнит метод работы. Не идеально для теста, где время выполнения должно быть очень быстрым. Простой способ обойти это - разделить рабочий код планирования на два отдельных класса. Затем частный метод работы становится общедоступным методом класса Worker, что упрощает его тестирование. Хотя разделение кода планирования и рабочего кода означает, что вам будет сложно достичь 100% покрытия, вы, по крайней мере, покроете рабочий код. Один из способов решения проблемы - использовать что-то вроде Quartz.net для реализации класса планировщика, чтобы вы могли легко модульно тестировать планировщик, а также рабочий код.

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

Я бы избегал принятого ответа.

Я могу разразиться тирадой о тестировании общедоступного интерфейса и не беспокоиться о внутреннем устройстве, но это может быть нереально.

Я вижу два немедленных варианта:

• Размышление, чтобы увидеть метод, своего рода взлом, но, по крайней мере, вы можете провести какой-то тест. Это также, вероятно, самый простой способ быстро приступить к работе.
• Абстрагируйте поведение частного метода, используя что-то вроде шаблона стратегии, и внедрите поведение в сам объект (или попросите объект внутри new выполнить соответствующую стратегию вручную). Затем этот отдельный элемент стратегии можно протестировать независимо.

При этом не стоит часто попадать в такую ​​ситуацию. Если вы это сделаете, вам нужно сделать шаг назад и пересмотреть, как вы проектируете свои классы, и, возможно, пересмотреть их, чтобы сделать их более открытыми и тестируемыми.

В VS 2005, 2008 и 2010 у вас может быть частный аксессор. Вы щелкаете правой кнопкой мыши частную функцию и выбираете «Создать частный аксессуар» ...

В VS 2012 эта функция как-то пропала. Единственный удобный способ - использовать PrivateObject. Вы можете проверить MSDN для примеров использования PrivateObject.

Используйте отражение. Если вы не хотите самостоятельно возиться с отражением, вы можете использовать класс Microsoft PrivateObject, расположенный в Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Но есть проблемы при взаимодействии MSTest и NUnit - Используете и MSTest, и NUnit?

Если вы используете VS 2005 или выше, выполните следующие действия.

1. Откройте файл исходного кода, содержащий частный метод.
2. Щелкните частный метод правой кнопкой мыши и выберите «Создать модульные тесты». Откроется диалоговое окно «Создание модульных тестов». В видимой древовидной структуре установлен флажок только для частного метода.
3. (Необязательно) В диалоговом окне «Создание модульных тестов» вы можете изменить выходной проект. Вы также можете нажать «Настройки», чтобы изменить способ создания модульных тестов.
4. Щелкните ОК. Это создает новый файл с именем VSCodeGenAccessors, который содержит специальные методы доступа, которые извлекают значения частных сущностей в тестируемом классе. Вы можете увидеть новый файл, отображаемый в обозревателе решений в папке тестового проекта. Если в вашем тестовом проекте до этого момента не было модульных тестов, также создается файл исходного кода для размещения модульных тестов. Как и файл, содержащий частные методы доступа, файл, содержащий модульные тесты, также отображается в вашем тестовом проекте в обозревателе решений.
5. Откройте файл, содержащий ваши модульные тесты, и перейдите к тесту для частного метода. Найдите утверждения, отмеченные // TODO: comments, и завершите их, следуя инструкциям в комментариях. Это помогает тесту давать более точные результаты.

Для получения дополнительной информации см. это

Похоже, что внутри он использует отражение для вызова частного метода. Но это работает.

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

Модульные тесты предназначены для тестирования интерфейса класса. Идея состоит в том, что я должен обеспечивать контроль качества при использовании моего класса так, как он предназначен. В результате бесполезно проводить модульное тестирование частного метода просто потому, что он никогда не будет открыт для потребителя (того, кто его реализует). Вам необходимо выполнить модульное тестирование для случаев, когда потребитель может использовать ваш класс.

Если вы обнаружите, что испытываете абсолютную потребность в модульном тестировании чего-то частного, вам может потребоваться переосмыслить расположение этого метода или то, как ваш код разбит на части. Я пришел к выводу, что если мне нужно провести модульное тестирование частного метода, в 9 из 10 раз это будет метод, который можно обернуть в статический служебный класс.