thetalkingwalnut запитує:
Які є хороші способи переконати скептично налаштованих розробників у цінності Unit Testing?
Усі тут збираються з безлічі причин, чому невідомо тестування. Однак я вважаю, що часто найкращий спосіб переконати когось у чомусь - вислухати їхній аргумент та звертатися до нього по пункту. Якщо ви слухаєте і допомагаєте їм висловити свої занепокоєння, ви можете звернутися до кожного з них і, можливо, перетворити їх на вашу точку зору (або, принаймні, залишити їх без ноги, щоб вони стояли). Хто знає? Можливо, вони переконають вас, чому одиничні тести не підходять для вашої ситуації. Не ймовірно, але можливо. Можливо, якщо ви опублікуєте їх аргументи проти одиничних тестів, ми можемо допомогти визначити контраргументи.
Важливо вислухати та зрозуміти обидві сторони аргументу. Якщо ви спробуєте прийняти одиничні тести занадто ревно, не зважаючи на занепокоєння людей, у вас закінчиться релігійна війна (і, мабуть, справді непридатні одиничні тести). Якщо ви приймете його повільно і почнете застосовувати його там, де ви побачите найбільшу користь за найменші витрати, ви, можливо, зможете продемонструвати цінність одиничних тестів і мати більше шансів переконати людей. Я усвідомлюю, що це не так просто, як це звучить - для формування переконливого аргументу зазвичай потрібен певний час і ретельні показники.
Одиничні тести - це інструмент, як і будь-який інший, і слід застосовувати таким чином, щоб вигоди (ловлі помилок) перевищували витрати (зусилля на їх написання). Не використовуйте їх, якщо / де вони не мають сенсу, і пам’ятайте, що вони є лише частиною вашого арсеналу інструментів (наприклад, перевірки, твердження, аналізатори коду, формальні методи тощо). Що я кажу своїм розробникам:
Вони можуть пропустити написання тесту для методу, якщо вони мають хороший аргумент, чому він не потрібен (наприклад, занадто простий, щоб бути вартим цього чи занадто важким, щоб бути вартим цього) і як метод буде перевірений в іншому випадку (наприклад, перевірка, твердження , формальні методи, інтерактивні / інтеграційні тести). Вони повинні враховувати, що деякі перевірки, такі як перевірки та офіційні докази, проводяться в певний момент часу, а потім їх потрібно повторювати щоразу, коли змінюється виробничий код, тоді як одиничні тести та твердження можуть використовуватися як регресійні тести (написані один раз і виконані повторно після цього ). Іноді я погоджуюся з ними, але частіше буду дискутувати про те, чи дійсно метод занадто простий чи занадто складний для тестування.
Якщо розробник стверджує, що метод здається занадто простим, щоб його не вдалося, чи не варто брати 60 секунд, необхідних для написання простого тесту на 5-рядковий блок? Ці 5 рядків коду працюватимуть щовечора (ви займаєтеся нічними побудовами, правда?) Протягом наступного року і більше, і варто буде докласти зусиль, якщо навіть раз, коли це трапиться, виникла проблема, яка може зайняти 15 хвилин або довше, щоб виявити і налагодження. Крім того, написання простих одиничних тестів збільшує кількість одиниць тестів, завдяки чому розробник виглядає добре.
З іншого боку, якщо розробник стверджує, що метод здається занадто важким для тестування одиниці (не варто вагомих значних зусиль), можливо, це є хорошим свідченням того, що метод потрібно розділити або відновити, щоб перевірити легкі частини. Зазвичай це методи, які покладаються на незвичні ресурси, такі як одиночні кнопки, поточний час або зовнішні ресурси, такі як набір результатів бази даних. Ці методи, як правило, повинні бути перероблені на метод, який отримує ресурс (наприклад, виклики getTime ()) і метод, який приймає ресурс як аргумент (наприклад, приймає часову позначку як параметр). Я дозволяю їм пропустити тестування методу, який отримує ресурс, і вони замість цього написали одиничний тест для методу, який тепер приймає ресурс як аргумент. Зазвичай це робить написання одиничного тесту набагато простішим і тому варто писати.
Розробнику потрібно намалювати «лінію в піску», наскільки комплексними повинні бути їх одиничні тести. Пізніше в розробці, коли ми знайдемо помилку, вони повинні визначити, чи могли б виявити більш комплексні тести одиниць. Якщо так, і якщо такі помилки з'являються неодноразово, їм потрібно перенести "рядок" на написання більш всеосяжних тестів на одиницю в майбутньому (починаючи з додавання або розширення одиничного тесту для поточної помилки). Їм потрібно знайти правильний баланс.
Важливо усвідомити одиничні випробування - це не срібна куля, і є таке поняття, як занадто багато тестових одиниць. На моєму робочому місці, щоразу, коли ми робимо вивчені уроки, я неминуче чую "нам потрібно написати більше одиничних тестів". Керівництво киває на згоду, тому що це їм вдарило в голову, що "одиничні тести" == "добре".
Однак нам потрібно зрозуміти вплив "більше одиничних тестів". Розробник може писати лише ~ N рядків коду на тиждень, і вам потрібно розібратися, який відсоток цього коду має бути одиничним тестовим кодом та виробничим кодом. Легке робоче місце може мати 10% коду як одиничне тестування і 90% коду як виробничий код, в результаті чого продукт має безліч (хоча і дуже баггі) функцій (думаю, MS Word). З іншого боку, у суворому цеху з 90% тестовими одиницями та 10% виробничим кодом буде надійний продукт з дуже мало функцій (подумайте "vi"). Ви ніколи не чуєте повідомлень про збій останнього продукту, але це, ймовірно, має стільки ж спільного з тим, що товар не продається дуже добре, як це стосується якості коду.
Що ще гірше, мабуть, єдина впевненість у розробці програмного забезпечення полягає в тому, що "зміни неминучі". Припустимо, суворий цех (90% одиниць тестів / 10% виробничого коду) створює продукт, який має рівно 2 функції (якщо припустити 5% виробничого коду == 1 особливість). Якщо замовник приходить і змінює 1 функцію, то це міняє сміття 50% коду (45% одиничних тестів і 5% виробничого коду). Магазин розрядки (10% одиниць тестів / 90% виробничий код) має товар з 18 особливостями, жодна з яких не працює дуже добре. Їх клієнт повністю переосмислює вимоги до 4-х своїх особливостей. Навіть незважаючи на те, що зміна в 4 рази більша, лише половина більшої частини коду потрапляє під удар (~ 25% = ~ 4,4% одиничних тестів + 20% виробничого коду).
Моя думка полягає в тому, що ви повинні повідомити, що ви розумієте, що баланс між занадто малою і занадто великою кількістю тестування одиниць - по суті, що ви продумали обидві сторони питання. Якщо ви можете переконати своїх колег та / або керівництво в цьому, ви здобудете авторитет і, можливо, маєте більше шансів перемогти їх.