Як мотивувати колег писати одиничні тести? [зачинено]

Ми працюємо над великим продуктом, який випускається вже близько 5 років. Кодова база працює .. ерм .. працює. Не дуже добре, але це працює. Нові функції кидаються у виробництво та перевіряються за допомогою невеликої якості. Помилки виправлені тощо. Але ніхто, крім мене, не пише одиничні тести. Ніхто не використовує силу «відстежувати» помилки, пишучи одиничні тести, щоб переконатися, що ця спеціальна помилка (тестовий випадок) ніколи не повториться.

Я спілкувався з менеджментом. Я спілкувався з розробниками. Я спілкувався з усіма в цілій компанії. Всі кажуть: "Так, ми повинні написати більше тестів!" Це було близько року тому. З цього моменту я змусив запровадити перегляд коду, що попередньо здійснює ( Герріт ) та постійну інтеграцію ( Дженкінс ).

Я провів кілька зустрічей з приводу тестування одиниць, а також показав переваги написання одиничних тестів. Але, схоже, ніхто не цікавиться.

Q1: Як мотивувати своїх колег писати тестові одиниці?

Q2: Як я мотивуюсь дотримуватися своїх стандартів якості особистого коду? (Іноді це дуже неприємно!)

PS: Деякі розчаровуючі факти (досягнуті за 1 рік):

• Всього одиниць тестів: 1693
• Всього "приклад одиничних тестів": близько 50
• Зроблено мною: 1521

Редагувати: чи я очікую занадто багато? Це моє перше робоче місце, і я намагаюся зробити все можливе.

Редагувати 2: На основі всіх відповідей я склав невеликий контрольний список для себе. Я розмовляв із двома розробниками приватно, і ми мали добрі та чесні розмови.

Один з них сказав мені, як і Теластин , що йому справді незручно з одиничними тестами. Він сказав, що хотів би бути "більш професійним", але йому потрібен швидкий старт. Він також сказав, що наша зустріч з тестовими підрозділами з усіма розробниками (близько 9-11) була хорошою, але вона була занадто людною. Мех. Деякі критики для мене, але я з цього навчусь. (див. відповіді нижче про проведення зустрічей з tdd kata!)

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

Наступного тижня я поговорю з іншими розробниками.

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

Я помітив, що говорити про TDD навряд чи працює. Людям подобається бачити сирі результати . Сказати, що "написання тестів скоротить час на розробку" , швидше за все, правда, але це може бути недостатньо, щоб когось переконати.

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

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

Що стосується порад, ви можете поїхати з TDD ката; Просте завдання для реалізації, використовуючи перший тестовий підхід, на відміну від тестів . Залежно від того, наскільки складним є завдання, нетестовий підхід, як правило, повинен бути повільнішим, особливо із необхідними покроковими змінами:

• Строковий калькулятор Роя
• Банк OCR

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

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

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

Результатом цих прикладів має стати просте запитання - якщо ви могли витратити години на розробку функції Y, чому б наполягати на тому, щоб це робити в 2 рази ?

Спочатку ви повинні знати, чому вони не пишуть тести.

Часто причина є щільний графік розробки, але ви кажете, що цього не маєте.

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

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

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

То як ви впораєтесь з різними причинами?

Причина перша проста, покажіть їм приклад того, як це економить час на розвиток.

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

Причина 3 - це навчання, а не просто показ. Змусити їх писати тести у навчальному класі.

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

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

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

Я б почав з демонстрації переваг TDD. Спробуйте показати переваги тестування одиниць.

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

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

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

Хороші посилання для подальшого читання:

• Чому слід писати одиничні тести
• Видимість мотивації та тестування одиниць
• Мистецтво одиничного тестування, за словами Роя Ошерове

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Я думаю, що я відзначив це посилання зі статті Джеффа Етвуда деякий час тому [редагувати: так , ось це] . Старий, але актуальний. Завдяки цим перевагам та іншим, які, безперечно, будуть викладені в інших відповідях, ваші програмісти повинні мати можливість мотивувати себе ! Це дозволить їм працювати ефективніше і таким чином полегшить роботу. Хто цього не хоче?

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

Це здається великим випадком приведення на прикладі .

Є два притаманні аспекти людської природи, з якими ти борешся:

• Творчі люди не люблять процес.
• Більшість людей не люблять зовнішніх негативних суджень про їх якість.

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

• Люди імітують поведінку кращих працівників

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

Запитайте їх.

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

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

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

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

Другий великий продавець - цикл QA. До початку TDD в моїй компанії ми штовхали нові випуски до QA для тестування. Вони б створили купу помилок із цього випуску, ми виправляємо ці помилки та натискаємо ще один випуск. Повторіть до кінця. Перший проект, який ми зробили TDD, не вимагав відстеження якості до декількох тижнів. А кількість знайдених помилок була дуже-дуже маленькою. 10% порівняно з аналогічним проектом. Чи маєте ви все-таки скласти ці статистичні дані для своєї команди?

Інша велика точка продажу полягала в тому, як кодекс виглядав після прийняття TDD, його було легше читати, адже ми хотіли спростити тестування. Показати порівняння між кодом, написаним для одиничних тестів, і кодом, не записаним.

Нарешті, покажіть їм, як вони зможуть з упевненістю перефактувати код.

Майте це на увазі, коли вам не подобається писати тести. :)

Я хотів би розкрити відповідь HLGEM , особливо цей розділ:

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

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

Спроба поставити тести на старий код, який не був написаний з урахуванням тестування, може бути неприємним.

Я використав кілька прийомів:

а) встановити автоматизовану збірку. Коли хтось зламає те, що ви перевірили, покажіть їм, як тест це виявив і наскільки погано був би помилка.

б) Робіть складні проекти з тестами (ви їдете). Це покаже, як мало помилок у цьому проекті. У мене був один складний проект взаємодії з сервером, який почав працювати бездоганно. Це ніколи не проваляло QA, і всі тести на інтеграцію пройшли на 100% плавно. Ця система стала відомою як дуже стабільна, і загальне керівництво нею було задоволено. Що ви робите в цих ситуаціях - це те, як тестування одиниць це дозволило.

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

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