Мені не подобається тестувати приватну функціональність з кількох причин. Вони наступні (це основні моменти для людей, які 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()це приватна функція! Таким чином, ми не можемо перевірити його так, оскільки він навіть не збирається (припускаючи, що ми використовуємо мову, яка фактично застосовує публічну / приватну, на відміну від деяких мов скриптів, таких як Python). Але як щодо зміни RuleEvaluatorкласу на дотримання принципу єдиної відповідальності (єдиного принципу відповідальності)? Наприклад, у нас, здається, є аналізатор, токенізатор та оцінювач, застряглі в одному класі. Чи не було б краще просто розділити ці обов'язки? Крім того, якщо ви створюєте Tokenizerклас, то це публічні методи були б HasMoreTokens()і GetNextTokens(). У RuleEvaluatorкласі може бути аTokenizerоб’єкт як член. Тепер ми можемо зберегти той же тест, що і вище, за винятком того, що ми перевіряємо Tokenizerклас замість RuleEvaluatorкласу.
Ось як це може виглядати в UML:
Зауважте, що цей новий дизайн збільшує модульність, тому ви могли потенційно повторно використовувати ці класи в інших частинах вашої системи (до цього ви не змогли приватні методи не використовувати повторно за визначенням). Це головна перевага розбиття оцінювача правил, а також підвищення зрозумілості / локальності.
Тест виглядав би надзвичайно схожим, за винятком того, що він би справді компілювався цього разу, оскільки 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 трохи раніше. Я в основному змінив цю відповідь, щоб бути тут більш агностичним мовою.
PS Ось відповідна лекція про уроки айсберга та інструменти для шпигування Майкла Пера: https://www.youtube.com/watch?v=4cVZvoFGJTU