Я не люблю тестировать приватную функциональность по нескольким причинам. Они заключаются в следующем (это основные моменты для людей TLDR):
- Обычно, когда вы испытываете желание протестировать закрытый метод класса,
это дизайнерский запах.
- Вы можете проверить их через публику
интерфейс (который, как вы хотите, чтобы проверить их, потому что это как
клиент будет звонить / использовать их). Вы можете получить ложное чувство безопасности,
видя зеленый свет на всех проходящих тестах для вашего частного
методы. Гораздо лучше / безопаснее тестировать крайние случаи в ваших личных функциях через открытый интерфейс.
- Вы рискуете серьезным дублированием теста (тесты, которые выглядят / чувствуются
очень похоже) путем тестирования частных методов. Это имеет важное значение
последствия, когда изменяются требования, столько же тестов, чем
необходимо сломать. Это также может поставить вас в положение, когда это
трудно реорганизовать из-за вашего набора тестов ... который является окончательным
ирония, потому что тестовый набор поможет вам безопасно переделать
и рефакторинг!
Я объясню каждый из них на конкретном примере. Оказывается, что 2) и 3) несколько запутанно связаны, поэтому их пример похож, хотя я считаю их отдельными причинами, по которым вам не следует тестировать частные методы.
Бывают случаи, когда уместно тестировать частные методы, просто важно знать о недостатках, перечисленных выше. Я расскажу об этом поподробнее позже.
Я также расскажу, почему TDD не является оправданием для тестирования частных методов в самом конце.
Рефакторинг вашего выхода из плохого дизайна
Один из самых распространенных (анти) паттернов, который я вижу, это то, что Майкл Фезерс называет классом "Айсберг" (если вы не знаете, кто такой Майкл Фезерс, иди купите / прочитайте его книгу «Эффективная работа с устаревшим кодом». Это человек, о котором стоит знать, если вы профессиональный инженер / разработчик программного обеспечения). Существуют и другие (анти) паттерны, которые приводят к возникновению этой проблемы, но на данный момент это самая распространенная проблема, с которой я столкнулся. У классов "Айсберг" есть один публичный метод, а остальные закрытые (вот почему заманчиво тестировать закрытые методы). Он называется классом «Айсберг», потому что обычно выявляется одинокий публичный метод, но остальная часть функций скрыта под водой в виде частных методов. Это может выглядеть примерно так:
Например, вы можете проверить GetNextToken(), последовательно вызывая его в строке и убедившись, что он возвращает ожидаемый результат. Такая функция требует проверки: это поведение не тривиально, особенно если ваши правила токенизации сложны. Давайте представим, что это не так уж сложно, и мы просто хотим привязать токены, разделенные пробелом. Итак, вы пишете тест, возможно, это выглядит примерно так (некоторый не зависящий от языка псевдо-код, надеюсь, идея ясна):
TEST_THAT(RuleEvaluator, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
re = RuleEvaluator(input_string);
ASSERT re.GetNextToken() IS "1";
ASSERT re.GetNextToken() IS "2";
ASSERT re.GetNextToken() IS "test";
ASSERT re.GetNextToken() IS "bar";
ASSERT re.HasMoreTokens() IS FALSE;
}
Ну, на самом деле это выглядит довольно мило. Мы хотели бы убедиться, что мы поддерживаем это поведение при внесении изменений. Но GetNextToken() является частной функцией! Так что мы не можем протестировать это так, , потому что он даже не скомпилирует (при условии, что мы используем какой-то язык, который на самом деле реализует public / private, в отличие от некоторых языков сценариев, таких как Python). Но как насчет изменения класса RuleEvaluator в соответствии с принципом единой ответственности (принцип единой ответственности)? Например, у нас, похоже, есть парсер, токенизатор и оценщик, объединенные в один класс. Не лучше ли разделить эти обязанности? Кроме того, если вы создадите класс Tokenizer, тогда его открытые методы будут HasMoreTokens() и GetNextTokens(). Класс RuleEvaluator может иметь в качестве члена объект Tokenizer. Теперь мы можем сохранить тот же тест, что и выше, за исключением того, что мы тестируем класс Tokenizer вместо класса RuleEvaluator.
Вот как это может выглядеть в UML:
Обратите внимание, что этот новый дизайн увеличивает модульность, поэтому вы можете потенциально использовать эти классы в других частях вашей системы (раньше вы не могли использовать закрытые методы по определению). Это является основным преимуществом разрушения RuleEvaluator вместе с улучшенной понятностью / локальностью.
Тест выглядел бы чрезвычайно похожим, за исключением того, что он на самом деле компилируется на этот раз, так как метод GetNextToken() теперь открыт для класса Tokenizer:
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS FALSE;
}
Тестирование частных компонентов через общедоступный интерфейс и предотвращение дублирования теста
Даже если вы не думаете, что можете разбить свою проблему на меньшее количество модульных компонентов (что вы можете сделать в 95% случаев, если просто попытаетесь сделать это), вы можете просто протестировать приватный функционирует через публичный интерфейс. Часто частные члены не стоит тестировать, потому что они будут протестированы через открытый интерфейс. Часто я вижу тесты, которые выглядят очень похожими, но тестируют две разные функции / методы. В конечном итоге происходит то, что когда требования меняются (а они всегда меняются), у вас теперь есть 2 неработающих теста вместо 1. И если вы действительно проверили все свои частные методы, у вас может быть больше 10 неработающих тестов вместо 1. Короче говоря, тестирование приватных функций (с помощью FRIEND_TEST или их публичное использование или рефлексия), которые в противном случае можно было бы протестировать через открытый интерфейс, может привести к дублированию теста . Вы действительно не хотите этого, потому что ничто не повредит больше, чем ваш набор тестов, замедляющий вас. Это должно сократить время разработки и снизить затраты на обслуживание! Если вы тестируете частные методы, которые в противном случае тестируются через открытый интерфейс, набор тестов вполне может сделать обратное и активно увеличить затраты на обслуживание и увеличить время разработки. Когда вы делаете приватную функцию общедоступной, или если вы используете что-то вроде FRIEND_TEST и / или рефлексии, вы, как правило, в конечном итоге пожалеете об этом в долгосрочной перспективе.
Рассмотрим следующую возможную реализацию класса Tokenizer:
Допустим, SplitUpByDelimiter() отвечает за возврат массива, так что каждый элемент в массиве является токеном. Кроме того, давайте просто скажем, что GetNextToken() - просто итератор по этому вектору. Итак, ваш публичный тест может выглядеть так:
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS false;
}
Давайте представим, что у нас есть то, что Майкл Фезер называет нащупывающим инструментом . Это инструмент, который позволяет вам прикоснуться к частным частям других людей. Примером является FRIEND_TEST из googletest или отражение, если язык поддерживает это.
TEST_THAT(TokenizerTest, canGenerateSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
result_array = tokenizer.SplitUpByDelimiter(" ");
ASSERT result.size() IS 4;
ASSERT result[0] IS "1";
ASSERT result[1] IS "2";
ASSERT result[2] IS "test";
ASSERT result[3] IS "bar";
}
Хорошо, теперь давайте скажем, что требования меняются, и токенизация становится намного более сложной. Вы решаете, что простого разделителя строк не будет достаточно, и вам нужен класс Delimiter для выполнения задания. Естественно, вы ожидаете, что один тест будет сорван, но эта боль усиливается при тестировании частных функций.
Когда может подойти тестирование частных методов?
В программном обеспечении не существует "одного размера для всех". Иногда нормально (и на самом деле идеально) «нарушать правила». Я настоятельно рекомендую не тестировать закрытые функции, когда это возможно. Есть две основные ситуации, когда я думаю, что все в порядке:
Я много работал с унаследованными системами (вот почему я такой большой поклонник Майкла Фезерса), и я могу с уверенностью сказать, что иногда просто безопаснее всего протестировать приватную функциональность. Это может быть особенно полезно для получения «тестов характеристик» в базовой линии.
Вы спешите, и вам нужно сделать как можно быстрее здесь и сейчас. В конце концов, вы не хотите тестировать частные методы. Но я скажу, что обычно требуется некоторое время на рефакторинг для решения проблем проектирования. И иногда вы должны отправить через неделю. Ничего страшного: делайте все быстро и грязно и тестируйте частные методы, используя инструмент поиска, если это то, что, по вашему мнению, является самым быстрым и надежным способом выполнения работы. Но поймите, что то, что вы сделали, было неоптимальным в долгосрочной перспективе, и, пожалуйста, рассмотрите возможность вернуться к нему (или, если об этом забыли, но вы увидите это позже, исправьте это).
Возможно, есть другие ситуации, когда все в порядке. Если вы думаете, что все в порядке, и у вас есть хорошее оправдание, тогда сделайте это. Никто не останавливает вас. Просто знайте о потенциальных затратах.
TDD Извините
Кроме того, мне действительно не нравятся люди, использующие TDD в качестве оправдания для тестирования частных методов. Я практикую TDD и не думаю, что TDD заставляет вас делать это. Вы можете сначала написать свой тест (для вашего открытого интерфейса), а затем написать код, удовлетворяющий этому интерфейсу. Иногда я пишу тест для общедоступного интерфейса, и я удовлетворяю его, написав также один или два небольших приватных метода (но я не тестирую приватные методы напрямую, но я знаю, что они работают, иначе мой публичный тест будет неудачным). ). Если мне нужно протестировать крайние случаи этого закрытого метода, я напишу целую кучу тестов, которые будут проходить через мой открытый интерфейс. Если вы не можете понять, как добиться успеха в крайних случаях, это сильный знак, который вам нужно реорганизовать в небольшие компоненты, каждый из которых имеет свои открытые методы. Это признак того, что частные функции слишком много делают и выходят за рамки класса .
Кроме того, иногда я нахожу, что пишу тест, который на данный момент слишком большой, чтобы жевать, и поэтому я думаю: «э, я вернусь к этому тесту позже, когда у меня будет больше API для работы с «(Я закомментирую это и буду держать это в уме). Именно здесь многие разработчики, которых я встречал, начнут писать тесты для своей частной функциональности, используя TDD в качестве козла отпущения. Они говорят: «О, ну, мне нужен какой-то другой тест, но для написания этого теста мне понадобятся эти закрытые методы. Поэтому, поскольку я не могу написать производственный код без написания теста, мне нужно написать тест». для частного метода. " Но то, что им действительно нужно сделать, - это рефакторинг на более мелкие и повторно используемые компоненты вместо добавления / тестирования множества частных методов в их текущий класс.
Примечание:
Я недавно ответил на похожий вопрос о тестировании частных методов с использованием GoogleTest . В основном я изменил этот ответ, чтобы сделать его более независимым от языка.
P.S. Вот соответствующая лекция Майкла Фезерса о классах айсберга и инструментах поиска: https://www.youtube.com/watch?v=4cVZvoFGJTU