TDD проти тестування блоку [закрито]

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

У спільноті TDD є багато людей, які дуже релігійні щодо написання тесту, а потім коду (і я з ними), але для команди, яка бореться з TDD, компроміс все ж приносить додаткові переваги?

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

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

EDIT

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

СЛІДУВАТИ

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

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

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

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

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

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

Я просто читав це в календарі: "Кожне правило, виконане в усіх можливостях, стає смішним або навіть небезпечним". Тому моя пропозиція не бути релігійною щодо цього. Кожен член вашої команди повинен знайти баланс між тим, що вони вважають «правильним», коли йдеться про тестування. Таким чином, кожен член вашої команди буде найпродуктивнішим (замість того, щоб сказати, думати "навіщо мені писати цей стильний тест **** ??").

Тож деякі тести краще, ніж жодні, тести після коду - кращі, ніж декілька тестів, а тестування перед кодом - краще, ніж після. Але кожен крок має свої достоїнства, і ви не повинні нахмуритися навіть на невеликі кроки.

TDD - це про дизайн! Тож якщо ви його використовуєте, ви обов'язково матимете тестовий дизайн свого коду, що полегшить написання тестів. Якщо ви пишете тести після написання коду, вони все ще цінні, але IMHO ви будете витрачати час, оскільки ви, мабуть, не матимете тестового дизайну.

Одне із пропозицій, яке я можу дати вам, щоб спробувати переконати вашу команду прийняти TDD - це використання деяких методів, описаних у « Безстрашних змінах: зразки впровадження нових ідей» Мері Лінн Меннс та Лінди Райз .

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

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

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

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

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

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

Близько 5 років тому я відкрив nUnit під час роботи над проектом. Ми майже закінчили V1.0, і я створив кілька тестів, щоб випробувати цей новий інструмент. У нас було багато помилок (очевидно!), Тому що ми були новою командою, у строгий термін, великі сподівання (звучать знайомо?) І т. Д. У будь-якому випадку ми отримали 1,0 і почали з 1,1. Ми трохи переорганізували команду, і мені було призначено 2 диски. Я зробив для них демонстрацію на 1 годину і сказав їм, що все, що ми писали, повинно мати з собою тестовий випадок. Ми постійно бігали «позаду» решти команди під час циклу 1,1 розробки, оскільки ми писали більше коду, тестові одиниці. Ми закінчилися працювати більше, але ось виплата - коли ми нарешті потрапили на тестування, у нас в коді було рівно 0 помилок. Ми допомагали всім іншим налагоджувати та виправляти свої помилки. У післясмертному періоді, коли з'явилася кількість помилок,

Я не дурний, щоб думати, що ти можеш перевірити свій шлях до успіху, але я справжній віруючий, коли справа стосується одиничних тестів. Проект прийняли nUnit, і незабаром він поширився на компанію для всіх проектів .Net в результаті 1 успіху. Загальний період часу для нашого випуску V1.1 склав 9 дев тижнів, так що це, безумовно, НЕ успіх ночі. Але довгостроково він виявився успішним для нашого проекту та компанії, для якої ми побудували рішення.

Немає сумнівів, що тестування (по-перше, поки або навіть після) врятує ваш бекон і підвищить вашу продуктивність та впевненість. Я рекомендую прийняти його!

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

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

Крім того, щоб бути тупим, я дізнався більше про те, як писати тестовий код, намагаючись перевірити написаний код, ніж починаючи з TDD. Спочатку це може бути занадто абстрактно, якщо ви намагаєтесь придумати договори, які одночасно мають досягти кінцевої мети та дозволять перевірити. Але коли ви подивитесь на код і зможете сказати: "Цей сингтон тут повністю псує залежність від ін'єкцій і робить тестування цього неможливим", ви починаєте розуміти, які зразки полегшують життя тестування.

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

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

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

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

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

Убік, але BDD також може представляти інтерес

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

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

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

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

• повідомляється про помилку
• створити тестовий клас JUnit при необхідності
• додайте тест, який відтворює помилку
• виправити свій код
• запустіть тест, щоб показати, що поточний код не відтворює помилку

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

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

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

Такий підхід працював для мене багато разів.

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

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

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

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

Зазвичай я роблю автоматизовані тести прийняття без обговорення, але дозволяю розробникам приймати TDD так, як їм підходить. Я маю досвідчених TDDers тренувати / наставляти решту та "доводити" свою корисність на прикладі протягом багато місяців.

Це стільки ж соціальна / культурна зміна, скільки технічна.