Зламані тести старого / застарілого блоку

Я працюю у великій компанії і відповідаю за велику програму java з тисячами тестів на джун. З того моменту, як я перейшов на цю роль, було 200-300 зламаних тестів (ймовірно, зламаних роками). Тести старі і тендітні, і вони є безладом залежностей від спагетті, які, як правило, закінчуються даними "пісочного".

Моя мета - 100% проходження тестів, щоб ми могли зламати нарощування відмов тестування одиниці, але я не можу це зробити, поки не звернуся до зламаних тестів. У мене дуже мало бюджету, оскільки бюджет на підтримку в першу чергу на підтримку, але моя команда визначила та виправила низько вивірені фруктові тести (переважно проблеми з конфігурацією / локальними ресурсами), і ми перейшли до 30-40 справді некрасивих тестів.

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

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

Який був би найкращий підхід?

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

Що б я зробив, це спершу вимкнути тести, які не вдається і завжди не вдається.

Зробіть так, щоб тест не мав значення.

Під час розслідування ви можете запитати людей, які довше були у вашій компанії, про них може бути багато племінних знань, які ви можете документувати / захопити. Можливо, з ваших журналів VCS. "О, цей тест завжди був невдалим, оскільки ми перейшли на X" або інша інформація може бути корисною.

Коли ви дізнаєтесь, яку функціональність перевіряли, ви можете визначити:

• Чи нас хвилює це тестування
• Наскільки важливо це перевірити

А потім складіть список пріоритетів.

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

Я б зробив наступне:

1. Спроба точно визначити, які невдалі тести намагаються перевірити.

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

3. Виправте все, що не так з кодом виробництва, коли у вас є хороші тести.

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

200-300 зламаних тестів (ймовірно, порушених роками).

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

Моя мета - 100% проходження тестів, щоб ми могли зламати нарощування відмов тестування одиниці, але я не можу це зробити, поки не звернуся до зламаних тестів.

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

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

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

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

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

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

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

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

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

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

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

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

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

Створюйте нові тести, які є релевантними, і продовжуйте писати чудовий код.