Ви б хотіли робити приватні речі внутрішні / загальнодоступні для тестів або використовувати якийсь хак, як PrivateObject?

Я досить початківець у тестуванні коду, і раніше був assertблудницею. Одне, що мене хвилює в одиничному тестуванні, - це те, що часто потрібно, щоб ви зробили public(або принаймні internal) поля, які були б privateінакше, щоб скасувати readonlyїх, замість цього зробити privateметоди protected virtualтощо.

Нещодавно я виявив, що ви можете цього уникнути, використовуючи такі речі, як клас PrivateObject, щоб отримати доступ до будь-якого об'єкта за допомогою відображення. Але це робить ваші тести менш рентабельними (речі не вдасться виконати, а не час компіляції; це буде розбито простим перейменуванням, важче налагодити ...). Яка ваша думка з цього приводу? Які найкращі практики тестування одиниць щодо обмеження доступу?

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

Вам ніколи не слід цього робити

зробити public(або принаймні internal) поля, які були б privateінакше, щоб скасувати readonlyїх, замість цього зробити privateметодиprotected virtual

Тим більше, що непрочитане поле може зробити незмінним об'єкт змінним, і це було б катастрофою.

Ваші тести повинні вважати ваші об'єкти чорними полями ( Wikipedia ), тобто вони повинні стосуватися лише публічного інтерфейсу об'єктів, а не деталей їх реалізації.

Якщо об’єкт не може бути достатньо протестований за допомогою його загальнодоступного інтерфейсу, то вам потрібно знайти способи надання формального та корисного розширення його інтерфейсу, який полегшить тестування. Наприклад, система реєстрації, що має лише пару методів Реєстрація / Скасування реєстрації, можливо, отримає користь від методу IsRegistered, навіть якщо це не потрібно для прикладної програми; все-таки це формальне і корисне розширення інтерфейсу, і воно, до речі, вмістить тестування.

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

У C # ви можете використовувати InternalsVisibleToAttribute щоб дозволити вашій тестовій збірці бачити internalкласи в тестуванні складання Здається, ви це вже знаєте.

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

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

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

Наскільки легко перевірити клас через його публічний API - це відгуки про те, наскільки легко буде використовувати клас. Подумайте про тести частково як про спосіб прототипу використання вашого класу.

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

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

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

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

Видимість вашого коду не має нічого спільного з вашими одиничними тестами!

Ви робите свої методи приватними не з метою приховувати їх від тестування, і ви не робите їх загальнодоступними для випробувань, правда? Тут важливо це ваша реалізація, а не тести - ті сервери як доказ вашого коду, але вони не ваш код .

Існує маса способів ввімкнути доступ до прихованих (приватних чи внутрішніх) методів та властивостей. Багато тестових рамок і IDE (наприклад, Visual Studio) підтримують вас тут, генеруючи все необхідне для доступу, вам залишається лише автор тесту. Отже, навіщо турбуватися? Краще зберігайте код чистим та акуратним.