How to Discuss Flaky Tests in English

Практичний посібник англійською мовою для обговорення фрагментарних тестів — як описати періодичні невдачі, запропонувати виправлення і відкинути культуру «просто перезапустити».

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

Ключовий словник

** Флакі- тест ** — тест, який дає різні результати (схвалений або невдалий) у різних запусках без будь- яких змін у коді або самому тесті.

  • “Тест замовлення не є точним — він зазнає невдачі приблизно раз на десять запусків, і це, здається, випадково.” *

** Перервна помилка ** — помилка, яка трапляється іноді, а не постійно, що ускладнює відтворення і діагностику. “Ми бачили періодичні помилки в тесті інтеграції платежу, але ми ще не пришпилили тригер.”

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

  • “Оказалося, що цей рівень тріщини є результатом перегонів між завершенням тестової налаштування і запуском фонового завдання.” *

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

  • “Ми втратили ізоляцію тестів, коли два тести почали запис до одного рядка бази даних — їх паралельне виконання спричинило помилки.” *

** Quarantine (тест) ** — тимчасове виключення відомого тесту з помилками з необхідного набору CI під час його дослідження, щоб не блокувати не пов’ язані з ним злиття.

  • “Ми поставили на карантин тест flaky і зареєстрували квиток, щоб він перестав блокувати всі не пов’ язані з ним запити на завантаження, поки ми розслідуємо.” *

** Корінь проблеми ** — основна причина, з якої перевірка з часом зазнає невдачі, на відміну від поверхневого симптому. “Коренева причина полягала не в самому тесті — це була спільна тестова база даних, яка не була повністю скинута між запусками.”

** Логіка повторних спроб (у CI) ** — автоматичне повторне виконання невдалого тесту один або два рази перед позначенням його як невдалого, часто використовується як проміжна зупинка для фрагментації. “Ми додали логіку повторних спроб як короткостроковий захід, але це обхідне рішення, а не виправлення — основна умова гонки все ще існує.”

** Сигнал (тестовий сигнал) ** - ступінь, в якій результат тесту пройшов / провалив надійно вказує на реальну проблему, на відміну від шуму. “Кожен неправильний тест, який ми залишаємо невирішеним, знищує довіру до всього набору — люди перестають довіряти сигналу і починають ігнорувати помилки.”

Використовується для тестування окремих компонентів команди

  • «Цей тест провалюється періодично — приблизно 5% запусків — і я ще не знайшов чіткого тригера»
  • “Все, похоже, связано с временем. Тест іноді запускається до того, як асинхронне завдання, від якого він залежить, було завершено»
  • “Я не думаю, що це справжній регрес. Ті ж самі тести не вдалися на main до цієї зміни, не пов’язані з тим, що ми злиємо»

Пропонування плану виправлення або розслідування

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

«Відновлення» (англ. Re-establishment) — культурний рух

У команд часто виникає звичай повторювати неефективні тести без проведення розслідування. Ось як конструктивно висловити свою занепокоєність:

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

Професійні поради

  1. ** Коли це можливо, оцінюйте кількісно нерівність. ** « Схибка 1 з 10 запусків » є більш дійсним, ніж « іноді не вдається »
  2. ** У описі відокремте симптом від кореневої причини. ** « Перевищено час очікування тесту » — це симптом; « перегони між налаштуванням і асинхронним завданням » — це ближче до кореневої причини.
  3. ** Карантину блоків як тимчасове, відстежене рішення. ** Без квитка і власника, тести, які знаходяться у карантині, часто забувають назавжди.

Практичні вправи

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

Навигація по нумерації: словник для тестів Flaky

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

Однією з поширених проблем є уникнення надмірно емоційної мови. Фрази на кшталт «Цей тест не спрацював!» негайно викликають конфронтацію і, ймовірно, припинять обговорення. Замість цього, розгляньте об’єктивніше трактування проблеми. Ви можете сказати: « Я спостерігаю періодичні невдачі цього тесту » або « Результати цього тесту здаються непослідовними ». Часто використовується ще один ключовий термін — * перехідний *. Перехідна помилка свідчить про тимчасову проблему, можливо, пов’ язану з факторами середовища, такими як затримка мережі або суперечка за ресурси. Описуючи невдалий тест як «перехідний за своєю природою», підступно переміщує фокус від звинувачення самого коду до потенційних зовнішніх впливів. Аналогічно, «спорадичні» невдачі корисні при описі тестів, які провалюються періодично без чіткого шаблону.

Крім окремих фраз, розуміння того, як ці поняття обговорюються в спільних каналах комунікації, є критичним. Давайте розглянемо кілька реалістичних сценаріїв. У коментарі до перегляду коду, замість простого повідомлення «Тест X зазнає невдачі», ви можете написати: «Тест X виявляє періодичні невдачі за певних умов (наприклад, під високим навантаженням). Я коротко розслідував, але основна причина не відразу з’ясувалася. Чи можемо ми дослідити потенційні фактори середовища або розглянути можливість додавання більш надійного журналювання для допомоги зневаджуванню?» Повідомлення Slack може бути таким: «Привіт, команда, я просто хотів позначити, що тест calculate_discount періодично зазнає невдачі — це, здається, тимчасова проблема. Я буду уважно стежити за цим і далі досліджувати, чи не повториться ця помилка. ” Нарешті, під час написання опису запитів на завантаження ви можете додати: « Цей запит на завантаження вводить зміни до логіки взаємодії з базою даних для облікових записів користувачів. Я запускав регресійний набір декілька разів, але тест validate_user_data продовжує виробляти спорадічні помилки. Я документую цю поведінку і приоритизую розслідування, як тільки будуть розглянуті інші високоприоритетні елементи»

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

Поширені запитання

Про що ця стаття "How to Discuss Flaky Tests in English"?

Практичний посібник англійською мовою для обговорення фрагментарних тестів — як описати періодичні невдачі, запропонувати виправлення і відкинути культуру «просто перезапустити».

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "How to Discuss Flaky Tests in English"?

Приблизно 7 min.