Отримайте кульку кочення на TDD

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

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

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

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

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

Але це ще не кінець. Після запуску цього тесту та запуску червоного кольору (демонстрація помилки в коді), знайдіть час, щоб з’ясувати, що не так (це потрібно робити у будь-якому випадку). Але поки не виправляйте. Як тільки ви виділите те, що, на вашу думку, є проблемою - напишіть одиницютест, який демонструє цю проблему. Тепер у вас є щось, з чим ви можете працювати (і, не випадково, вам, можливо, довелося б переробити козирок ще до більшої достовірності). Виправити помилку. Слідкуйте за проходженням тестового блоку. Можливо, м'якоть це з якихось крайових корпусів; Отримайте одну одиницю - ту, яка лише коштувала вам двох тижнів часу - міцну та чисту та добре перевірену. Тепер запустіть тест регресії і поспостерігайте, як він пройде (звичайно, якщо цього не відбудеться, у вас є ще кілька досліджень і роботи на рівні одиниці - ітерайте, поки він теж не пройде). Перевірте це все. Що у вас є? Регресійні тести для раніше невдалого коду. Одиничні тести на попередньо невдалий код. Невдалий робочий код. Краще розроблений код, тому що зараз він більш перевірений, ніж був. Краща впевненість у своїй кодовій базі,

Це не "чистий" TDD. Але він швидко демонструє результати та покращує якість коду з часом. Результати допоможуть вам придбати управління.

У моїй компанії я щойно перейшов із методом «тільки бурчання» від JoelOnSoftware і почав писати одиничні тести, коли я, як правило, просто зламав би якусь програму консольного викидання. Я почав робити справи набагато швидше, стабільніше випускаючи, і помітив це. На запитання, що я роблю, я пояснив, що почав використовувати TDD і писати тести одиниць кожного разу, коли змінював старий код або писав будь-який новий код. Мої колеги-розробники почали цікавитись і самі почали використовувати інтегровані тести. Я не думаю, що є хороший аргумент для написання тестів для працюючого застарілого коду, але якщо ви можете зробити так, що написання автоматизованих тестів відбувається швидше і зручніше, ніж писати спагеті для злому спагеті, то розумні розробники будуть слідувати далі.Інші переваги, які спричинять підвищення якості програмного забезпечення, будуть також існувати, але ключовим фактором для входу в розробник є те, що це полегшує їхнє життя. Що стосується підписання бізнесу, той факт, що це призведе до кращого програмного забезпечення та, ймовірно, займе менше часу для доставки, ніж раніше, має бути більш ніж достатньо, щоб переконати їх.

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

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

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

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

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

Бажаю удачі та успіху!