Альтернатива індикатору "Прохідна / зламана збірка"?

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

Я маю деякі проблеми з цим:

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

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

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

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

Чи є спосіб зробити безперервну інтеграцію та сумісним TDD?

Можливо, є стандартне рішення / практика для розмежування "нових тестів" (які можуть не вдатися) та "регресійних тестів" (які не повинні провалюватися, оскільки вони працювали)?

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

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

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

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

Знову ж таки, я не можу наголосити на важливості. Не вчинити порушений код ніколи! Ваш внесок не може вплинути на роботу інших програмістів.

Редагувати

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

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

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

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

Зберігайте свою головну гілку чистою та зеленою в усі часи. Робота у філії. Тримайте відділення під CI в окремій роботі і пройдіть невдалі тести на вміст вашого серця. Просто не зламайте майстра.

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

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

Почну з проблеми створення "зламаного тесту", який відповідає квитку. Одне рішення - створити один або кілька тестів на розрив, які викривають проблему, а потім фактично виправити проблему , щоб вони могли бути об'єднані назад до основного рядка коду разом. Другим рішенням є те, що зламані тести, але використовувати якийсь тип прапора ігнорування, щоб вони насправді не виконувались і не порушували збірку. Можливо, додайте коментар або спеціальну анотацію, яка дає зрозуміти, що це зламаний тест Ticket#N. Також додайте примітку до самого квитка, яка посилається на створені тести, які чекають, щоб їх не було ігноровано та запущено. Це допоможе людині, яка фіксує квиток, але також не буде червоним прапором для того, хто натрапить на тест.

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

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

Я думаю, що ваша основна проблема полягає в тому, що ви включаєте тестові РЕЗУЛЬТАТИ як частину складання. Хоча, очевидно, деякі люди згодні з вами, інші - ні. Порушення збірки відбувається, коли воно не будується. Не тоді, коли він не створюється без помилок.

Розглянемо такий великий проект, як Windows або Linux, або навіть щось на зразок Firefox - ти вважаєш, що вони доставляють помилок? Звичайно, ні. Зараз ці проекти не роблять TDD, але це справді не має значення - TDD не змінює два фундаментальні факти: помилки існують, і для їх виправлення потрібен час. Час, який проект (з відкритим кодом чи ні) просто не може дозволити собі витрачати на помилки з низьким пріоритетом. Нещодавно у KDE виправлено помилку, яку виправлено понад десятиліття. Коли в останній раз ви чули, щоб хтось сказав: "Я радий, що ми чекали десятиліття, щоб відправити наш проект"?

TDD, певним чином, ймовірно, робить його ЛЕГШЕМЕ відправляти з помилками - тому що ви краще розумієте, що таке недолік. Якщо ви зможете точно визначити, що викликає помилку, у вас є відмінна основа для зважування витрат на її виправлення.

Моя рекомендація - знайти проект, який не проти червоного серед зеленого.

 > a common best practice is to have all the tests passing (green) at all times.

Я вважаю за краще, щоб усі тести не були відмовними (не червоними).

За допомогою цього дещо іншого визначення ви також можете визначити тести, які є

• ще не впроваджено (сірий у nunit, якщо є NotImplementedException)
• як відомо, що не працює = "потребує виконання", позначаючи / коментуючи тест як ігнорований (жовтий)

Якщо ви перевіряєте їх у сховищі, то ваша безперервна збірка не порушена і тому дійсна.

Ви можете розглянути два різних "побудови" побудови ІС.

1. Регулярні побудови ІС. Регулярна збірка CI повинна компілювати та запускати лише ті тести, для яких написано код, щоб вони пройшли, так що звіти CI про тестування / невдачу тесту є явним, однозначним показником регресу проти раніше прийнятого стану коду.

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

   • Тести можуть бути додані для конкретних випадків відмов у трекері випусків, для яких ще не було зроблено спроб виправлення. Очевидно корисно мати вже кодифікований, запущений тест для проблеми навіть без виправлення.

   • Додано тести на нову необхідну функціональність, яка ще не була реалізована.

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

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

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

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

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

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

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

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

• Фітнес має концепцію очікуваного невдачі.
• JUnit має @Ignored / @Test (очікувати =)
• Огірок має статус "ще не реалізований" (або як його ще називають)

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

Я використовую пропущені тести.

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