скільки часу ви витрачаєте на тестування одиниць?

У компанії, в якій я працював, керівники наполягали на тому, що покриття коду тестами підрозділу повинно становити 99% або більше. Це призвело до написання більше тестів, ніж код. На те, щоб скласти тести для одного класу, на реалізацію якого пішов день, нам знадобилося буквально 3 дні.

Однак у результаті я дізнався багато про TDD, інструменти тестування, практику тощо.

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

Зараз, як самозайнята людина, мені цікаво - скільки часу насправді потрібно витратити на тестування одиниць? Які частини коду повинні бути охоплені тестами, будучи переважно розробником iPhone / Android?

Кількість одиничного тестування, яке потрібно, залежить від кількох факторів:

• Розмір продукту (чим більший проект, тим більша потреба включити принаймні деякі одиниці тестування)
• Необхідний рівень якості (Якщо ви швидко збираєте програмне забезпечення, яке повинно бути якнайшвидшим, і деякі незначні помилки є прийнятними, можливо, ви будете змушені пропустити тестування, як тестування одиниць)
• Тип продукту (користувальницькі інтерфейси можуть бути перевірені одиницею, але іноді простіше пропустити тестування одиниць на важких розділах GUI проекту та замість цього випробувати вручну)
• Ваша здатність / історія кодування (який тип помилок ви зазвичай створюєте? Це речі, які зазвичай тестує модуль тестування, або речі, які зазвичай знаходить інший тип тестування. Знаючи, що це може підштовхнути вас до більш-менш тестування одиниць)

У нашій групі продуктів ми орієнтуємось на 50-70% покриття коду від одиничних тестів та 90% + покриття від одиничних тестів та автоматизації тестування разом. Типовий час, розрахований на написання одиничних тестів, становить приблизно 1 день для кожної функції, яка займає 3-4 дні кодування головою вниз. Але це може змінюватись у багатьох факторах.

99% покриття коду чудово. Тести одиниці чудові. Але 99% покриття коду від лише тестування одиниць? Мені важко повірити в те, що ти можеш отримати стільки покриттів лише від одиничного тестування .

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

Але ви сказали, що три дні тестового написання були лише для одного класу. Можливо, сам клас не був розроблений для одиничного тестування. Чи реалізує клас інтерфейс користувача? Мережі? Файл вводу / виводу? Якщо так, то, можливо, ви написали більше коду для тестування часу виконання Java, ніж ваша бізнес-логіка, яка взаємодіє з програмою.

TDD змушує задуматися з точки зору інтерфейсів та інтерфейсів залежностей. Цей єдиний клас, який реалізує інтерфейс користувача, мережу та файл / io для однієї функції, може бути краще розбитий на кілька класів - один для мереж, один для файлу / io та інтерфейс інтерфейсу, розбитий на модель моделювання глядача-контролера. Тоді ви можете реалізувати відповідні тести для кожного з простих макетних об'єктів для залежностей. Звичайно, все це займає більше часу. Отже, замість 1 дня кодування та 3 днів для написання тестів, для цього типу дизайну може знадобитися 3 дні кодування та 1 день написання тестів. Але код буде набагато краще реконструйований та багаторазовий.

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

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

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

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

Якщо ви не витратите час на тести, ви витратите ще більше часу на налагодження в реальному коді.
Тому витрачайте стільки часу, скільки потрібно на тести, щоб покрити весь (або 99% коду).

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

99 +% одиничного покриття тестом схоже, можливо, занадто багато, щоб очікувати у випадку середнього додатка, але занадто мало для життєво важливого проекту.

На моєму досвіді, враховуючи, що значна частина виробничого коду - це код поводження з помилками, покриття 80-90% було б достатнім для більшості програм, і це може зажадати приблизно стільки ж часу, витраченого на написання одиничних тестів, як і виробничий код. (Знову ж таки, якщо хтось серйозно працює в режимі TDD, вони повністю переплітаються, щоб практично стати однією єдиною задачею, тому можна лише здогадатися оцінити фактичне співвідношення.)