Частный код модульного тестирования

Как заявил Крис, стандартной практикой является модульное тестирование только общедоступных методов. Это потому, что вы, как потребитель этого объекта, заботитесь только о том, что вам публично доступно. И теоретически правильные модульные тесты с граничными случаями будут полностью проверять все имеющиеся у них зависимости частных методов.

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

Если это так, вы все равно можете вызывать частные методы с помощью отражения.

MyClass obj = new MyClass();
MethodInfo methodInfo = obj.GetType().GetMethod("MethodName", BindingFlags.Instance | BindingFlags.NonPublic);
object result = methodInfo.Invoke(obj, new object[] { "asdf", 1, 2 });
// assert your expected result against the one above

у нас есть цикломатическое правило, которое гласит, что ни один метод не должен иметь цикломатическую сложность больше 5

Мне нравится это правило.

Дело в том, что частные методы - это детали реализации. Они могут быть изменены / рефакторингом. Вы хотите протестировать публичный интерфейс.

Если у вас есть частные методы со сложной логикой, рассмотрите возможность их рефакторинга в отдельный класс. Это также может помочь снизить цикломатическую сложность. Другой вариант - сделать метод внутренним и использовать InternalsVisibleTo (упомянутый в одной из ссылок в ответе Криса).

Уловки, как правило, возникают, когда у вас есть ссылки на внешние зависимости в частных методах. В большинстве случаев для разделения классов можно использовать такие методы, как внедрение зависимостей. Для вашего примера со сторонней структурой это может быть сложно. Я бы сначала попробовал реорганизовать дизайн, чтобы отделить сторонние зависимости. Если это невозможно, рассмотрите возможность использования Typemock Isolator. Я не использовал его, но его ключевая особенность - возможность "имитировать" частные, статические и т. Д. Методы.

Классы - это черные ящики. Испытайте их таким образом.

РЕДАКТИРОВАТЬ: Я постараюсь ответить на комментарий Джейсона к моему ответу и отредактировать исходный вопрос. Во-первых, я думаю, что SRP подталкивает к большему количеству классов, а не от них. . Да, лучше избегать классов помощников швейцарской армии. Но как насчет класса, предназначенного для обработки асинхронных операций? Или класс поиска данных? Являются ли они частью ответственности исходного класса или их можно разделить?

Например, предположим, что вы перемещаете эту логику в другой класс (который может быть внутренним). Этот класс реализует асинхронный шаблон проектирования, который позволяет вызывающей стороне выбирать, будет ли метод вызывается синхронно или асинхронно. Модульные или интеграционные тесты написаны для синхронного метода. Асинхронные вызовы используют стандартный шаблон и имеют низкую сложность; мы их не тестируем (кроме приемочных испытаний). Если класс async является внутренним, используйте InternalsVisibleTo для его проверки.

На самом деле вам нужно рассмотреть только два случая:

1. частный код вызывается прямо или косвенно из открытого кода и
2. частный код не вызывается из открытого кода.

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

Ergo: нет необходимости явно тестировать частный код.

Обратите внимание, что когда вы выполняете TDD, даже существование непроверенного частного кода невозможно. Потому что, когда вы выполняете TDD, единственный способ появления частного кода - это рефакторинг Extract {Method | Class | ...} из общедоступного кода. А рефакторинг по определению сохраняет поведение и, следовательно, сохраняет тестовое покрытие. И единственный способ появления общедоступного кода - это результат неудачного теста. Если общедоступный код может отображаться как уже протестированный код только в результате неудачного теста, а частный код может появиться только в результате извлечения из общедоступного кода посредством рефакторинга с сохранением поведения, отсюда следует, что непроверенный частный код никогда не может появиться.

На протяжении всего моего модульного тестирования я никогда не утруждал себя тестированием private функций. Обычно я просто тестировал public функции. Это согласуется с методологией тестирования черного ящика.

Вы правы, что действительно не можете тестировать частные функции, если не предоставите частный класс.

Если ваш «отдельный класс для тестирования» находится в той же сборке, вы можете использовать внутренний вместо частного. Это открывает доступ к внутренним методам вашему коду, но эти методы не будут доступны для кода не в вашей сборке.

РЕДАКТИРОВАТЬ: поиск по этой теме я натолкнулся на этот вопрос. Ответ, получивший наибольшее количество голосов, аналогичен моему ответу.

Несколько замечаний от специалиста по TDD, который копался в C #:

1) Если вы программируете для интерфейсов, то любой метод класса, которого нет в интерфейсе, фактически является частным. Вы можете найти это лучший способ повысить тестируемость, а также лучший способ использования интерфейсов. Протестируйте их как публичные участники.

2) Эти небольшие вспомогательные методы могут более правильно принадлежать к какому-то другому классу. Ищите зависть к особенностям. То, что может быть неприемлемым в качестве частного члена исходного класса (в котором вы его нашли), может быть разумным публичным методом класса, которому он завидует. Протестируйте их в новом классе как публичные члены.

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

4) Вы можете получить «тестируемый» класс из оригинала, в котором тривиальная задача - создать новый общедоступный метод, который ничего не делает, кроме вызова старого частного метода. Тестируемый класс является частью тестовой среды, а не частью производственного кода, поэтому иметь специальный доступ - это здорово. Протестируйте его в тестовой среде, как если бы он был общедоступным.

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

Здесь есть несколько отличных ответов, и я в основном согласен с повторяющимся советом по выращиванию новых классов. Однако для вашего примера 3 есть хитрый и простой прием:

Пример 3. Вы используете стороннюю платформу, которая позволяет вам расширяться путем переопределения защищенных виртуальных методов (путь от общедоступных методов к этим виртуальным методам обычно рассматривается как программирование черного ящика и будет иметь все виды зависимостей, которые предоставляет платформа, которые ты не хочешь знать о)

Допустим, MyClass расширяет FrameworkClass. Попросите MyTestableClass расширить MyClass, а затем предоставить общедоступные методы в MyTestableClass, которые предоставляют защищенные методы MyClass, которые вам нужны. Не лучшая практика - это своего рода средство для плохого дизайна, но иногда полезно и очень просто.

Будут ли работать вспомогательные файлы? http://msdn.microsoft.com/en-us/library/bb514191.aspx Я никогда не работал с ними напрямую, но знаю, что один из коллег использовал их для тестирования частных методов в некоторых Windows Forms.

Несколько человек ответили, что частные методы не следует тестировать напрямую или их следует переместить в другой класс. Хотя я считаю, что это хорошо, иногда оно того не стоит. Хотя я в принципе согласен с этим, я обнаружил, что это одно из тех правил, которые нельзя нарушать, чтобы сэкономить время без негативных последствий. Если функция небольшая / простая, накладные расходы на создание другого класса и тестового класса слишком велики. Я сделаю эти частные методы общедоступными, но не буду добавлять их в интерфейс. Таким образом, потребители класса (которые должны получать интерфейс только через мою библиотеку IoC) случайно не будут их использовать, но они доступны для тестирования.

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

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

Я знаю, это некрасиво, но я думаю, что это хорошо работает.

Я признаю, что, когда недавно писал модульные тесты для C #, я обнаружил, что многие приемы, которые я знал для Java, на самом деле не применимы (в моем случае это было тестирование внутренних классов).

Например, 1, если вы можете подделать / имитировать обработчик извлечения данных, вы можете получить доступ к обратному вызову через подделку. (Большинство других языков, которые я знаю, используют обратные вызовы, как правило, не делают их частными).

Например, 2 я бы посмотрел на запуск события, чтобы проверить обработчик.

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

1. В любом случае протестируйте весь класс (или хотя бы соответствующие его части). Это особенно работает в тех случаях, когда абстрактный базовый класс поставляется со своими собственными тестами или общий класс не слишком сложен. В Java я мог бы сделать это, если бы, например, писал расширение AbstractList. Это также может иметь место, если шаблон шаблона был сгенерирован путем рефакторинга.

2. Снова расширьте класс дополнительными хуками, которые позволяют напрямую вызывать защищенные методы.

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

Существуют методы (макеты, заглушки) для правильного тестирования черного ящика. Посмотрите их.

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

SRP - wikipedia / pdf

Это также приводит к более надежному и адаптируемому коду, поскольку принцип единственной ответственности на самом деле просто говорит о том, что ваш класс должен иметь высокий уровень сплоченность.

В C # вы можете использовать атрибут в AssemblyInfo.cs:

[assembly: InternalsVisibleTo("Worker.Tests")]

Просто пометьте свои частные методы внутренними, и тестовый проект по-прежнему будет видеть этот метод. Простой! Вы можете сохранить инкапсуляцию и пройти тестирование, без всякой ерунды TDD.