Іноді приватні функції просто ще мають бути вилучені внутрішні одиниці функціональності. То чому б не перевірити їх?

Іноді приватні функції модуля або класу просто ще мають бути вилучені внутрішні одиниці функціональності, які, можливо, заслуговують на власні тести. То чому б не перевірити їх? Ми будемо писати тести для них пізніше, якщо / коли вони будуть вилучені. То чому б не написати тести зараз, коли вони все ще є частиною одного файлу?

Демонструвати:

По-перше, я писав module_a. Тепер я хочу написати для цього тести. Я хотів би перевірити функцію 'приватне' _private_func. Я не розумію, чому я б не написав тест на нього, якщо пізніше я все-таки можу повернути його до власного внутрішнього модуля, а потім написати тести для нього.

Припустимо, у мене є модуль із такими функціями (це також міг бути клас):

def public_func(a):
    b = _do_stuff(a)
    return _do_more_stuff(b)

_do_stuffі _do_more_stuffє "приватними" функціями модуля.

Я розумію ідею, що нам слід перевірити лише публічний інтерфейс, а не деталі реалізації. Однак ось що:

_do_stuffі _do_more_stuffмістять більшість функціональних можливостей модуля. Кожен з них може бути публічною функцією іншого, "внутрішнього" модуля. Але вони ще не розвинулися і досить великі, щоб їх можна було витягнути для окремих файлів.

Тому тестування цих функцій вважається правильним, оскільки вони є важливими одиницями функціональності. Якби вони були в різних модулях як публічні функції, ми б їх протестували. То чому б не перевірити їх, коли вони ще не (або коли-небудь) були вилучені в інший файл?

Необхідність перевіряти не така, як потреба бути публічною.

Нетривіальний код потребує тестування незалежно від впливу. Недержавна поведінка не повинна існувати, не кажучи вже про те, щоб її перевірити.

Ці суперечливі погляди можуть призвести до того, що ви хочете оприлюднити кожну функцію або відмовитись від факторного кодування до функції, якщо вона не буде загальнодоступною.

Це не відповідь. Будьте готові створити приватні функції помічників. Перевірте їх через загальнодоступний інтерфейс, який максимально використовує його.

Якщо тестування через публічний інтерфейс не виконує приватну функцію в достатній мірі, приватна функція намагається дозволити багато чого.

Перевірка може допомогти звузити те, що дозволяє приватна функція. Якщо ви не можете пропустити нуль, проходячи через загальнодоступний інтерфейс, ви все одно можете викинути виняток, якщо такий все-таки пройде.

Чому ви повинні? Навіщо тестувати те, що ніколи не побачиш? Тому що все змінюється. Він може бути приватним зараз, але публічним буде пізніше. Код виклику може змінитися. Код, який явно відхиляє нуль, робить зрозумілим правильне використання та очікуваний стан.

Звичайно, нульове може бути добре. Тут просто приклад. Але якщо ви чогось очікуєте, корисно уточнити це очікування.

Це, можливо, не те саме тестування, яке ви мали на увазі, але, сподіваємось, ви будете готові створити приватні допоміжні функції, коли це доречно.

Бажання протестувати добре, але воно не повинно бути рушійною силою в дизайні вашого публічного API. Створіть загальнодоступний API простий у використанні. Ймовірно, це не буде, якщо кожна функція є загальнодоступною. API повинен бути те, що люди можуть зрозуміти, як користуватися, не занурюючись у код. Не залишайте таких людей цікавими, для чого ця дивна помічниця.

Приховування загальнодоступних функцій помічників у внутрішньому модулі - це спроба поважати потребу в чистому API під час викриття помічників для тестування. Я не скажу, що це неправильно. Можливо, ви робите перший крок до іншого архітектурного шару. Але, будь ласка, оволодійте мистецтвом тестування приватних помічницьких функцій через загальнодоступні функції, які спочатку їх використовують. Таким чином, ви не перестанете використовувати цей спосіб вирішення.

Коротка відповідь: Ні

Більш відповідь: Так, але через загальнодоступний "API" вашого класу

Вся ідея приватних членів класу полягає в тому, що вони представляють функціональність, яка повинна бути невидимою поза "одиницею" коду, якою б великою ви не хотіли б визначити цей блок. У об'єктно-орієнтованому коді ця одиниця часто виявляється класом.

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

Після уточнення питання це лише питання семантики. Якщо код, про який йде мова, може працювати як окремий окремий блок і перевіряється так, ніби він був публічним кодом, я не бачу ніякої користі від того, щоб не переміщувати його в окремий модуль. В даний час він служить лише для того, щоб заплутати майбутніх розробників (в тому числі і вас, через 6 місяців) щодо того, чому, мабуть, загальнодоступний код ховається в іншому модулі.

Вся суть приватних функцій полягає в тому, що вони приховані деталі реалізації, які можна змінювати за бажанням, не змінюючи публічний API. Для вашого прикладу код:

def public_func(a):
    b = _do_stuff(a)
    return _do_more_stuff(b)

Якщо у вас є ряд тестів, які використовуються лише public_funcтоді, ви можете переписати їх на:

def public_func(a):
    b = _do_all_the_new_stuff(a)
    return _do_all_the_old_stuff(b)

тоді, поки результат повернення для певного значення aзалишається однаковим, тоді всі ваші тести будуть хорошими. Якщо результат повернення зміниться, тест не вдасться, підкресливши той факт, що щось зламалось.

Це все добре: статичний публічний API; добре укладені внутрішні вироби; і надійні випробування.

Однак, якщо ви писали тести для _do_stuffабо _do_more_stuffпотім вносили вищезгадані зміни, у вас зараз з'явиться купа зламаних тестів не тому, що змінилась функціональність, а тому, що реалізація цієї функціональності змінилася. Ці тести потребували б переписування для роботи з новими функціями, але, змусивши їх працювати, все, що ви знаєте, - це те, що вони працювали з новими функціями. Ви втратили б оригінальні тести, і тому не знали б, чи public_funcзмінилася поведінка, і тому ви тести були б марними.

Це погана річ: мінливий API; викриті внутрішні роботи, щільно поєднані з тестами; і крихкі тести, які змінюються, як тільки вносяться зміни до впровадження.

Тому ні, не перевіряйте приватні функції. Колись.