Чи слід навмисно порушувати збірку, коли виявлено помилку у виробництві?

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

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

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

Наша стратегія:

Перевірте невдалий тест, але зауважте його @Ignore("fails because of Bug #1234").

Таким чином, тест є, але збірка не руйнується.

Звичайно, ви помічаєте проігнорований тест у db bug, тому @Ignoreвидаляється, коли тест буде виправлено. Це також служить простою перевіркою на виправлення помилок.

Сенс руйнування складання невдалих тестів полягає не в тому, щоб якось піддавати команду тиску - це сповістити їх про проблему. Після виявлення проблеми та подання в БД помилок, немає сенсу проводити тестовий запуск для кожної збірки - ви знаєте, що вона вийде з ладу.

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

Чому ви хочете дозволити збірці досягти успіху з відомими дефектами?

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

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

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

"Розбити збірку" означає запобігти успішному завершенню збірки . Невдалий тест цього не робить. Це вказівка ​​на те, що збірка має відомі дефекти, що є абсолютно правильним.

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

Я б заперечував, що тест, який провалюється, повинен бути доданий, але не явно як "провальний тест".

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

Що ви повинні запитати себе в цій ситуації, це

Які тести мають бути виконані?

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

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

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

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

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

Якщо сказати іншим способом ... Збірка вже порушена. Все, що ви вирішили - це звертати увагу на цей факт чи ні.

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

Написання тесту, який, на вашу думку, не вдасться, поки помилка не буде виправлена ​​- це гарна ідея, це основа TDD.

Розбити склад - погана ідея. Чому? Тому що це означає, що нічого не може рухатися далі, поки це не буде виправлено. Це по суті блокує всі інші аспекти розвитку.

Приклад 1
Що робити, якщо ваша програма відрізняється великим розміром і має багато компонентів? Що робити, якщо ці компоненти працюють над іншими командами з власним циклом випуску? Жорстко! Вони повинні чекати виправлення вашої помилки!

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

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

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

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

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

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

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

Ви не хочете, щоб допомогти вашій команді ввійти в цю думку.

Тому я погоджуюся з sleske, що ви повинні додати тест, але позначити його як "ігнорувати" для автоматичної збірки, поки помилка не буде виправлена.

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

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

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