Який сенс запускати одиничні тести на сервері CI?

98

Навіщо проводити одиничні тести на сервері CI?

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

— Стів
джерело

51

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

— Борис Павук

2

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

— Пер Лундберг,

130

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

— jpmc26

5

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

— anaximander

5

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

— чукшмаш

223

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

Чи ні. Причин, чому це може статися, може бути багато:

У розробника немає дисципліни для цього
Вони забули
Вони не здійснили все і підштовхнули незавершений набір зобов'язань (спасибі Матьє М.
Вони провели лише кілька тестів, але не весь набір (спасибі nhgrif )
Вони протестували на своїй гілці до об'єднання (спасибі nhgrif * 2)

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

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

Інші вагомі причини побудови CI для запуску тестів:

Тестування на інших платформах, окрім основних платформ розробки, що може бути важко для розробника. (спасибі TZHX )
На сервері CI можуть запускатися тести прийняття / інтеграції / від кінця до кінця / дійсно довгі запущені тести, які зазвичай не запускаються на вікні розробника. (спасибі Ixrec )
Розробник може зробити невеликі зміни, перш ніж натискати / вчиняти (думаючи, що це безпечна зміна, а отже, не запускаючи тести). (спасибі Ixrec * 2)
Конфігурація сервера CI зазвичай не включає всі інструменти розробника та конфігурацію, і тому ближче до виробничої системи
Системи CI будують проект з нуля кожного разу, тобто збірки повторюються
Зміна бібліотеки може спричинити проблеми нижче за течією - сервер CI може бути налаштований для створення всіх залежних баз коду, а не лише бібліотеки

— Одіє
джерело

36

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

— Іхрек

11

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

2

@MichaelT Хороший улов. Це насправді причина> 90% наших збоїв в

— ІП

34

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

— mgarciaisaia

5

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

— Саймон Ріхтер

74

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

Мені доведеться створити, протестувати та перевірити, чи програма працює правильно:

Microsoft Windows XP та Vista з компілятором Visual Studio 2008.
Microsoft Windows 7 з компілятором Visual Studio 2010.
- О, і MSI будує для кожного з них.
RHEL 5 і 6 з 4.1 і 4.4 відповідно (аналогічно CentOS)
- 7 скоро. Ву-де-вуп.
Робоча станція Fedora з GCC для останніх трьох останніх версій.
Debian (та похідні, такі як Ubuntu) для останніх трьох останніх версій.
Mac OSX в останніх трьох останніх версіях.
- І пакети (rpm, dmg тощо)

Додайте до Fortran (як для компіляторів Intel, так і для GNU), Python (і це різні версії залежно від ОС) та компоненти сценарію bash / bat, і, я думаю, ви можете бачити, що речі спіральні.

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

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

— TZHX
джерело

3

Код тестування блоку не конфігурації. Було б серйозно інертно додати новий тест і кинути його через стіну, навіть не запускаючи його локально спочатку ...

— Роббі Ді

33

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

— TZHX

7

@RobbieDee Я б сказав, що TZHX буде виконувати всі тести локально, якби вони могли це зробити, але вони не можуть . Оскільки TZHX не може, вони виконують локальні тести (ті, які можуть працювати на їхній програмі розробок і досить короткі, або найбільш відповідні зміненому коду, наприклад), і дозволяють повністю заряджати батарею в системі CI. Досить розумний.

— муру

11

@RobbieDee: Він вірить у тестування одиниць. Тож він тестує їх у своєму Macbook в ефірі, проходить і перевіряє. Сервери CI під управлінням Red Hat, Solaris і Windows потім запускають ці тести ще раз. Хіба не приємно знати, що тестованість ви також працює на виробничих платформах?

— slebetman

2

@RobbieDee: Я часто писав Unit Tests, які були специфічними для певного компілятора на певній платформі. Розглянемо, наприклад, графічну підсистему, яка використовує спеціальні інструкції процесора для AMD (конкурента Intel), які доступні лише у g ++ (компілятор GNU C ++) версії 4.5 або новішої, але я буваю працювати над процесором Atom та ICC (Intel C ++ Укладач). Запускати AMD / g ++ 4.5-тести щоразу на цій машині було б нісенітницею, але це код, який потрібно перевірити перед випуском; плюс мій власний незалежний від процесора код повинен бути перевірений на належну сумісність. Звичайно, є віртуальні пристрої та емулятори, ...

— phresnel

23

Окрім чудової відповіді Оді:

Ви перевіряєте код із сховища . Це може працювати на вашій машині з вашими файлами ..., які ви забули зробити. Це може залежати від нової таблиці, в якій немає сценарію створення (наприклад, у ліквідній базі), деяких конфігураційних даних або файлів властивостей.
Ви уникаєте проблем інтеграції коду. Один розробник завантажує останню версію, створює тест одиниці та інтеграції, додає код, проходить весь тест на своїй машині, робить і натискає. Ще один розробник зробив те саме. Обидві зміни правильні самі по собі, але при об'єднанні викликає помилку. Це може бути об'єднання сховища або просто те, що воно не буде виявлено як конфлікт. Наприклад, Dev 1 видаляє файл, який взагалі не використовувався. Код Dev 2 проти цього файлу та тести без змін Dev 1.
Ви розробляєте сценарій для автоматичного розгортання із сховища. Наявність універсального сценарію побудови та розгортання вирішує багато питань. Деякі розробники, можливо, додали параметр lib або компіляція, який не всім поділяють. Це не тільки економить ваш час, але ще важливіше, що робить розгортання безпечним та передбачуваним. Крім того, ви можете повернутися до свого сховища до версії 2.3.1 і розгорнути цю версію за допомогою сценарію, який працює з цією версією. Вона включає об'єкти бази даних, такі як представлення даних, збережені процедури, погляди та тригери, на які слід ввести версію. (Або ви не зможете повернутися до справної версії).
Інші тести : як інтеграція, продуктивність і тести на кінці. Це може бути повільним і може включати засоби тестування, такі як Selenium. Можливо, вам знадобиться повний набір даних із реальною базою даних замість макетних об'єктів або HSQL.

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

— Борджаб
джерело

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

— гострий зуб

22

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

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

Ваші тести можуть також покладатися на локальний (не зареєстрований) ресурс. Щось тестування вашого місцевого підрозділу не знайдеться.

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

— Роббі Ді
джерело

7

Я бачив більше ой, я забув здійснити ті невдачі CI, які я хочу визнати.

— Дан Нілі

@DanNeely Чесно кажучи, це б'є, що ваш удар вкладає менеджер збірки, тому що ви забули сказати йому / їй про щось ... :-)

— Роббі Ді

3

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

— Дан Нелі

14

до того моменту, коли щось буде віддане майстру

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

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

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

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

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

— Даєніт
джерело

1

У вас не повинно бути повільних тестів на одиницю - це порушує ПЕРШІ принципи.

— Роббі Ді

4

@RobbieDee: Я думаю, що зазвичай сервер CI виконує всі тести, а не лише одиничні тести.

— РемкоГерліч

4

@RobbieDee: теоретично всі одиничні тести швидкі. На практиці .... Незалежно від того, CI може і повинен виконувати всі випробування - лінери, статичний аналіз, одиничні тести, інтеграційні тести.

— Daenyth

2

@RobbieDee Очевидно, специфіка конфігурації буде відрізнятися від команди до команди. Навіть коли збірки займають кілька хвилин, часто можна запускати кілька цих збірок паралельно. Враховуючи єдину монолітну кодову базу, це може бути більшим недоліком, але IME - це не бар'єр.

— Даніят

1

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

— Daenyth

4

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

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

— Девід Арно
джерело

3

Якщо припустити (всупереч іншим відповідям), що розробники досить дисципліновані і виконують одиничні тести перед вчиненням, то може бути кілька причин:

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

— БЈович
джерело

3

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

Уявіть собі поїзд, що рухається двома локомотивами A і B. Однак якщо два "виправлення" застосовуються, видаляючи обидва, поїзд не рухатиметься.

Крім того, не всі розробники виконують всі тести Unit, тоді як більшість хороших розробників.

— h22
джерело

2

Давайте задамо рівнозначне запитання:

Навіщо ви будувати код на сервері CI?

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

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

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

— Петро
джерело