Як переконати товаришів по команді використовувати TDD [закрито]

Я єдина людина в моїй команді, яка використовує TDD. Як змусити їх використовувати його?

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

Чи вирішить цю проблему використовувати github, fork та pull запит, щоб їм потрібно було пройти тест до того, як витяг буде прийнятий?

Я не керівник проекту, і, здається, не можу переконати її використати.

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

Як ви описуєте проблему, схоже, це не так. Подивіться ...

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

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

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

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

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

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

... Що буде, коли розробка тестових програм буде представлена ​​вашим недосвідченим колегам?

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

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

Коли я хотів заохотити використання тестових програм, я керував Cyber-Dojo . При такому вправі акцент робиться не на самому коді, а на процесі написання коду .

Ми провели південь, парами, повторюючи ту саму ката, але за різних умов. Ми почали з усіх груп одночасно робити одну вправу. Це забезпечило базову лінію.

Потім ми обговорили деякі основні принципи TDD, змусили всіх поміняти партнерів і повторити ту саму ката. Ми повторили ту саму ката, щоб зняти акцент на генерації коду і замість цього зосередити людей на процесі називання тестових випадків та циклу Червоний / Зелений.

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

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

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

Люди загалом казали, що полудень був і веселим, і інформативним, і зараз ми розглядаємо інші способи використання Cyber-Dojo на моєму робочому місці.

Cyber-Dojo , написаний Джоном Джаггером , неймовірно добре працює для такого роду вправ. Це є веб-інтегрованої середовищем для виконання усвідомленої практики в TDD і вивчення динаміки команди. У ньому є безліч ката, вибраних спеціально для того, щоб допомогти людям зосередитись на процесі TDD, а не на проблемі. Він також підтримує різноманітні мови: від Python та Ruby до Java та C ++.

Найкраще, після того, як ви зробите ката, ви зможете повернутися назад і подивитися на червоний / зелений прогрес (а може і не * 8 ') кожної з груп, що беруть участь. Саме світлофори - прекрасний спосіб уявити, як працює процес TDD.

Якщо ви хочете мати власний сервер CyberDojo, весь проект можна знайти на github, і там навіть пов'язана віртуальна машина пристрою під ключ Linux , а це означає, що якщо ви вже встановили програвач VMware або VirtualBox , ви можете бути запущеними та запущеними в межах кілька хвилин завантаження пристрою!

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

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

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

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

Справді важко переконати людей змінити свої звички, але ось що можна спробувати:

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

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

Тут є дві дещо різні проблеми: змусити людей робити TDD та людей, які порушують ваші тести.

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

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

Як сказано в багатьох інших "як мені переконати X використати метод Y / метод Y", моя відповідь завжди однакова: на прикладі.

Використовуйте його та матимете кращі (заспокійливі) результати. Потім переконайтесь, що інші помітять.

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

Багато хороших порад. А тепер ще трохи ...

Ви повинні завойовувати серця і розум (ЧИМ) по одній Люддіті за раз. Забудьте про те, щоб змусити його за горло. Багато предметних уроків протягом невизначеного (вибачте за це) періоду часу. Врешті-решт, ви потрапите на критичну масу, переконайте «правильних» осіб.

Ваш постійний і послідовний ентузіазм та ухилення від TDD дуже важливий у кампанії WHAM.

Ви повинні перетворити тестові розбиття та зміни коду в зрозумілі моменти, уроки яких важливі для ваших кодерів. Зробіть це особистим. IE Чи вони піклуються про репутацію за те, що вони отримують вище середнього чистого коду? Невже їх не турбує керівництво, яке їм запізнюється щодо коду, який запізнився, оскільки тестери інтеграції дали їм перевірку реальності? У Джека є бажання змінити складний код, але боїться побічних ефектів?

Збери хороші приклади тестування, як захоплення помилок, спричинених кодером. Кодери побачать зміну тестів як непотрібну роботу з невідповідним кодом; вони повинні розуміти, що тести просто покривали їхні дупи.

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

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

Попередження: TDD не є засобом для лікування та не може подолати поганий дизайн та кодування OO (але це, безумовно, може викрити це). Не дозволяйте лудитам звинувачувати коди тестування в їх некомпетентності.

Я б спробував ще раз переконати менеджера. З того, що ви написали, я не думаю, що ви могли переконати своїх товаришів по команді зробити TDD за її спиною.

Ви повинні розмовляти її мовою. Менеджер, як правило, не вражає технологіями, але вони розуміють ділову мову:

• тести заощадять час під час розробки, тому що замість ручного тестування (намагання відтворити помилку на локальному рівні, граючи з консоллю рейки ...), ви будете запускати тести автоматично

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

• і що ви будете робити з додатковим часом? створити речі з мурашника і змусити їх грошей :)

Що стосується програмістів, спробуйте цей аргумент (він працював на мене, зворотній шлях): "Ви все одно тестуєте код, з TDD або без нього. Тільки ви робите це вручну, а не автоматизувати його. Розумні розробники автоматизують стільки речей, скільки можуть. "

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

Чому сміттєзбірник не любить, не вчиться та живе RAII? Як ви могли виборювати автоматичне управління пам’яттю, але дотримуватися старомодного управління загальними ресурсами, такими як файли, з'єднання тощо? Оскільки RAII - це технологія, яку вони не знають, не розуміють і не мають часу використовувати, коли у них є термін, який потребує виконаної роботи.

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