Як боротися з величезною кількістю невдалих тестів? [зачинено]

Я працюю над розробкою старого проекту, написаного на Java. У нас більше 10 мільйонів LOC і, що ще гірше, понад 4000 функціональних тестів.

Тести, заплановані Хадсоном, не спрацьовують з розуму при кожній більшій зміні коду. Перевірка несправності тесту - якщо це проблема в продукті або в тесті, займає місяці. Ми не можемо видалити старі тести, оскільки ми не знаємо, що вони тестують!

Що ми можемо зробити? Як приступити до такої кількості застарілих тестів?

Відмовитися від них.

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

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

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

Перейдіть і виправте тести.

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

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

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

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

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

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

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

Тимчасово відключіть невдалі тести.

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

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

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

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

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

У крайньому випадку ви можете видалити код з HEAD системи управління версіями, але це ускладнить розпізнавання, коли третя фаза буде завершена.

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

Тримайте тести відповідними.

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

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

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

Визначте наміри кожного тесту.

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

• Чи перевіряється вона функцією, яку спеціально було видалено з бази коду? Тоді ви, ймовірно, можете її видалити.

• Хіба це зловлення клопа, якого ще ніхто не помітив? Повторно встановіть тест і виправте помилку.

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

• Чи розповсюджується тест по всій програмі та чи є тест системи? Потім вийміть його з вашого основного тестового набору Дженкінса і додайте його до набору регресій, який працює рідше.

• Чи змінилася архітектура програми до невпізнання, тому тест більше не робить нічого корисного? Видаліть його.

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

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

4000 тестів - нерозв'язна проблема. 40 тестів є більш простежуваними. Випадково виберіть керовану кількість тестів для запуску та аналізу. Класифікуйте результати як:

1. Марний тест
2. Корисний тест, який працює в чистоті
3. Корисний тест, який не вдається

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

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

Якщо це твердження вірно,

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

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

Повторюйте, поки у вас не буде остання база коду.

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

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

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

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

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

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

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

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

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

Ми не можемо видалити старі тести, оскільки ми не знали, що вони тестують!

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