які функції та / або класи неможливо перевірити, і чому

Головним приводом розробника за те, що він не мав належного тестування, - це "Код не розроблений в одиничному порядку". Я намагаюся зрозуміти, який тип дизайну та код не можна перевірити.

Кілька факторів можуть ускладнити код для перевірки. У такому випадку рефакторинг допомагає покращити код, щоб він міг бути перевіреним.

Деякі приклади коду, які, ймовірно, будуть важко перевірити:

• Функція 1000 LOC,
• Кодекс, який сильно покладається на глобальну державу,
• Код, який вимагає конкретних, складних для побудови об'єктів, таких як контекст бази даних, замість того, щоб покладатися на інтерфейси та введення залежності,
• Код, який працює повільно ,
• Код спагетті,
• Спадковий код, який змінювався роками, не дбаючи про читабельність чи ремонтопридатність,
• Важко зрозуміти код, який не має коментарів чи натяків на оригінальний намір автора (наприклад, код, який використовує назви змінних, таких як function pGetDp_U(int i, int i2, string sText).

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

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

• Закон про порушення Деметра .
• Створення об'єктів всередині методу замість введення залежностей .
• Щільна муфта.
• Погана згуртованість.
• В основному покладається на побічні ефекти.
• В основному покладається на глобали або одинаки.
• Не піддає багато проміжних результатів. (Мені колись довелося перевірити математичну функцію на десять сторінок з одним виходом і відсутніми доступними проміжними результатами. Мої попередники в основному жорстко кодували будь-яку відповідь, на яку стався код).
• Залежить в значній мірі і безпосередньо від сервісів, з яких важко глузувати, як-от баз даних.
• Навколишнє середовище виконання значно відрізняється від середовища розробки, як вбудована мета.
• Одиниці доступні лише у складеному вигляді (як-от сторонні DLL).

Найпоширеніші приклади коду, які люди не бажають проводити на тестуванні:

• Код, який безпосередньо взаємодіє з вводу-виводу (читання файлів, прямі мережеві дзвінки,…).
• Код, який безпосередньо оновлює інтерфейс користувача.
• Код, який безпосередньо посилається на одиночні або глобальні об'єкти.
• Код, який неявно змінює стан об'єкта чи суб'єкта.

Використовуючи макетну рамку, всі ці приклади можна перевірити на одиницю. Це просто робота з налаштування макетних замін на внутрішні залежності.

Те, що справді не може бути перевірено одиницею:

• Нескінченні петлі (для менеджера потоків, драйвера чи іншого типу тривалого коду)
• Певні типи операцій прямого збирання (які підтримують деякі мови)
• Код, який вимагає привілейованого доступу (не неможливо, просто непогана ідея)

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

Погано написано розробленого коду

• невідповідна муфта (як правило, щільна муфта там, де її не має бути)
• код кухонної мийки (де функція має занадто багато логіки / обов'язків)

Опора держави в іншому масштабі

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

• Сінглтон
• Глобали
• Закриття

Зовнішній / системний стан

• Залежності від обладнання та пристрою
• Мережеві залежності
• Залежності файлової системи
• Міжпроцесові залежності
• Інші залежності системних викликів

Паралельність

• Нитка (замки, критичні секції тощо)
• розщеплення
• Розслідування
• Резервні дзвінки
• Обробники сигналів (не всі, але деякі)

Немає такого поняття, як код, який не можна перевірити. Однак є кілька прикладів коду, ЩО СТАТИСТЬ, СТАТИСТЬ важко перевірити (до речі, можливо, не варто витрачати зусиль):

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

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

Мої основні три групи для цього:

• код, який покладається на зовнішні сервіси

• системи, які не дозволяють тестерам змінювати стан незалежно від програми.

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

Це те, що я пережив найбільше, як розробник, який перетворився на QA-інженера.