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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тепер поставте пріоритети на те, що ви хочете робити. Визначте пріоритетні завдання, завжди знаючи, що вашим першим пріоритетом завжди буде поточне завдання проекту ... Щодо вашої тестової проблеми, ось що я б робив, у три етапи:

1. Як змінити тест на одиницю та інтеграцію? Наступні рішення можуть застосовуватися і не є ексклюзивними:

   • Refactor назва методів тестових випадків (не класи, оскільки правильна поведінка полягає в тому, щоб тестовий випадок мав те саме ім'я, що і тестований клас)
   • Створіть дві анотації, одну з яких називають "UnitTest", а іншу - IntegrationTest. Ці анотації можна використовувати на заняттях та на методах. Якщо весь клас складається з одиничних або інтеграційних тестів, ви можете позначити клас правильною анотацією. Якщо ні, ви можете позначити кожен метод правильною анотацією. Крім того, ці примітки можуть бути корисними для динамічного введення світильників перед запуском тестів (фаза 3)

2. Для кожного тесту на інтеграцію перелічіть, що таке "набір даних", який очікується у базі даних на початку кожного тесту, і що слід видалити в кінці його (наприклад: таблиця X, потрібен запис із "id" встановити на "1", а "ім'я" встановити на "foo" тощо). Зауважте, що те, що ви видаляєте, може бути більшим / меншим, ніж у вас на початку, оскільки сам код може відповідно додати / видалити об'єкти із шару стійкості. Ви, швидше за все, швидко помітите, що для декількох цих тестових випадків потрібен той же набір даних або частина одного набору даних.

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

Ви можете зауважити, що фази 1, 2 і 3 можуть бути виконані на одному тестовому класі, якщо ви швидко хочете показати колегам / керівництву, як це можна зробити. Це також було б корисно, як писав Петер Тьорек, щоб негайно показати «хороший шлях» своїм товаришам по команді, щоб вони перестали виробляти поганий код. Однак я думаю, що решту фази 2, що визначає весь тестовий набір даних, найкраще виконати за один великий крок.

Що стосується API / технології, яка стоїть за усім цим, то, здається, ви знаєте тему.

Сподіваюся, що трохи допомогло.

Примітка: для моєї пропозиції я вважаю, що ви кодуєте або в Java / C # там, де я знаю, що примітки та AOP можливі. Я впевнений, що це можливо і на інших мовах, але я не пишу про те, чого не знаю.

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

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

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

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

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

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

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

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

IMO Вашою першою ціллю має бути запобігання команді виробляти більше поганих тестів . Тому почніть з демонстрації переваг кожного конкретного вдосконалення своїм товаришам по команді. Якщо вони побачать корисність певної техніки - будь то вирізання зовнішніх залежностей, відновлення початкового стану після кожного тесту або розділення блоку та тестів інтеграції - вони почнуть застосовувати їх. Це само по собі повільно, але точно покращить загальну якість тестової бази в довгостроковій перспективі (якщо у вас зараз 1000 поганих тестових випадків, а команда виробляє 1000 хороших тестів до наступного року, ви знизили співвідношення поганих тестів від 100% до 50%). Після того, як це забезпечено, ви можете вирішити питання про рефакторинг існуючих тестів у кожному конкретному випадку. Знову ж таки, невеликі вдосконалення з часом призведуть до великих змін.

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

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

Будьте терплячі та поважайте людей, з якими ви працюєте, незважаючи на безлад, який вони створили. Вони намагаються зробити все правильно, за всією ймовірністю; пам’ятайте про це і допомагайте їм це робити.

Хороша річ у тому, щоб бути новим у команді - це те, що ти маєш «свіжий» підхід до речей. Погана частина може полягати в тому, що іншим може бути важко повірити вам.

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

Але візьміть це повільно, одна за одною, і сподівайтеся, що ваші ідеї повільно "наздоганяють" серед нової групи.

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

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

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

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

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

Виправте їх з часом

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

Мені особисто все одно, чи тест є одиничним тестом чи інтеграційним тестом, якщо це хороший тест. Під хорошим тестом я маю на увазі, що це:

• прибирає після себе
• є повторюваним
• мінімізує екологічні взаємодії
• є послідовним

По дорозі я евангелізував кращу тестову конструкцію (що означає, що я багато клопотів людей).