Постійна інтеграція з тестуванням корисна для того, щоб переконатися, що у вас постійно перевіряється код "shippable".
Однак насправді важко тримати вичерпний набір тестів, і часто це відчуває, що складання все одно буде баггі.
Скільки випробувань ви повинні мати впевненість у своєму тестуванні на конвеєрне обладнання? Чи використовуєте ви якусь метрику, щоб вирішити, коли достатньо тестів?
Відповіді:
Коли у вас достатньо автоматичного тестування, щоб бути впевненим у своїй постійній інтеграції?
Відповідь, ймовірно, стає зрозумілою, якщо ви подумаєте про те, в чому хочете бути впевненим. Зрештою, він відображає 1-1; кожен тест дає вам впевненість у тому, що тестує:
Наприклад, із того, як ви сформулювали своє запитання, ви, напевно, зараз думаєте у великому бізнесі, наприклад:
Я хочу бути впевнений , що моє додаток може зробити X .
Таким чином, ви пишете тест для завершення, який намагається зробити X, і перевіряє, чи правильно це робиться.
Це все дуже самореференційно, але це тому, що саме так воно і зводиться. Просто цього не більше.
Наприклад, уявіть, що ви пишете додаток для створення рецептів приготування. Однією з особливостей є те, що якщо ви додаєте різні кількості декількох різних видів сиру, це дає вам правильну температуру та час, щоб усі вони плавилися.
Таким чином, ви можете написати одиничний тест для свого CheeseMeltCalculator, де ви дасте 100 г Ґуда та 200 г сиру Емменталь, а потім перевірте, що температура та час виходять правильними. Це означає, що тепер ви можете бути впевнені, що CheeseMeltCalculatorпрацює на 100 г сиру і 200 г сиру. Тепер, якщо ви повторите цей тест з 300г Gouda замість 200g, ви можете бути впевнені, що він працює правильно для різних значень. Ви можете додати тести для 0, -1і int.MaxValueг Гауда , щоб бути впевненим в тому , що код не підніжки (або поїздки правильно , як передбачався) для дивного введення.
Ви можете написати тест на інтеграцію, щоб перевірити, CheeseMeltCalculatorчи правильно він включений у весь процес обчислення температури та часу їжі. Якщо це піде не так, але CheeseMeltCalculatorтести, наведені вище, добре, ви можете бути впевнені, що помилка є в інших калькуляторах або в поєднанні даних різних калькуляторів.
І, нарешті, ви можете написати цільовий тест для створення цілого рецепту, і одна з речей, яку ви перевіряєте, - це температура та час результату. Якщо попередні два рівні тестів добре, але це піде не так, то ви знову можете бути впевнені, що ці частини є правильними і помилка полягає в тому, як обчислення температури інтегрується в додаток. Наприклад, можливо, введення користувача неправильно передано.
І, нарешті , якщо всі ці тести добре, тоді ви можете бути впевнені, що " якщо ви додасте різні кількості кількох видів сиру, це дає вам правильну температуру та час, щоб усі вони плавилися "
Справа в тому, що ви не можете мати тест "він працює правильно". Ви можете перевірити лише "Якщо я зроблю X, Y станеться".
Однак це саме той матеріал, який повинен бути в технічних характеристиках проекту. Заява на зразок " якщо ви додаєте різні кількості кількох різних видів сиру, це дає вам правильну температуру та час, щоб усі вони плавилися " не тільки дає клієнту чіткі очікування щодо того, що буде робити готовий продукт, але і його можна повернути в автоматизовані тести.
Користувач Річард додав цю інформацію в редагуванні:
Мартін Фаулер на своєму веб-сайті має дуже приємне резюме про найпоширеніші стратегії: https://martinfowler.com/articles/microservice-testing/
Я не хочу цього видаляти, але хочу сказати так: У порівнянні з цією відповіддю, це не «резюме», а скоріше набагато більш поглиблене пояснення, з приємною графікою і все.
Моя порада була б: Якщо для вас все має сенс після прочитання моєї відповіді, ви закінчите. Якщо все ще здається незрозумілим, відкладіть трохи часу і прочитайте пов’язану статтю.
Ви не можете обчислити показник, який дасть вам впевненість, яку ви шукаєте. Впевненість будується, роблячи щось, а потім досягати успіху або невдачі і чомусь із цього вчитися.
Єдиний «показник», який я знайшов, що дає мені впевненість у нашому тестовому покритті:
Автоматизовані випробування - це не срібна куля. Потрібно відслідковувати, скільки виробничих дефектів виявлено протягом кожного циклу випуску. Коли ця кількість зменшиться, ви пропонуєте краще програмне забезпечення. Автоматизовані тести та безперервна інтеграція - це лише інструменти, які ви використовуєте для забезпечення кращого програмного забезпечення.
Єдиний показник, який ви дійсно можете виміряти, - "Чи постачаєте ви краще програмне забезпечення?"
І навіть тоді це суб'єктивно.
Коли у вас достатньо автоматичного тестування, щоб бути впевненим у своїй постійній інтеграції?
У більшості економічних умов у вас не буде бюджету, щоб реалізувати достатню довіру (> 99%), але вам доведеться керувати обмеженим бюджетом: все стосується співвідношення витрат і вигод.
Тож насправді легкі / дешеві / ризиковані тести будуть реалізовані, тоді як дорогі / малоймовірні тести не будуть.
Однією з цілей softwaredevelopment є створення архітектури, яку легко / дешево перевірити (спроектувати тест за допомогою застосування Test-driven_development ), щоб автоматичне тестування було доступним.
Я припускаю, що Pareto_principle також може бути застосований до програмного забезпечення, яке може бути тестуваним, і тут: Це говорить про те, що витрачаючи додатково на 20% більше грошей, ви отримуєте 80% додаткової вигоди. Щоб досягти решти 20% більшої вигоди, потрібно витратити додаткові 80% грошей.
Ви можете застосувати тестові показники, такі як покриття коду та мутація, щоб показати потенційний неперевірений вихідний код.
Але навіть маючи 100% покриття, ви не можете бути впевнені, що ваш код не містить помилок.
Керівництво любить кодеметрику. Якщо "охоплення кодом> = 80%" забезпечується управлінням, тоді як розробники не підтримують / як автоматичне тестування, є способи написання тестового коду з високим покриттям, що не підтверджує нічого, що дає помилкове відчуття безпеки.
Трюк тут - не турбуватися про повне охоплення, а в управлінні ризиком змін.
Скажімо, ви використовуєте ваш конвеєр для розгортання тієї самої версії, що вже є у виробництві - який ризик виникнення помилки регресії? Нуль (тому що змін немає).
Скажімо, я хочу змінити фрагмент тексту на одному з екранів. Я додав тест, щоб перевірити, чи текст тепер відображається правильно (припустимо, для аргументу це дійсно важливий фрагмент тексту). Які ще тести мені потрібні, щоб перевірити відсутність регресійних помилок? Реально ні ...
Тож кількість автоматизованих тестів, необхідних для кожного випуску в реальному часі, залежить не від розміру вашої програми, а від розміру вашої зміни. Якщо ви вносите невеликі зміни з низьким рівнем ризику, тоді вам знадобиться набагато менше тестів для зменшення ризиків.
Але зачекайте хвилинку ... чи не дуже це поєднується з точки зору CI та CD?
Так! Зберігаючи всі ваші зміни та дельти дуже маленькими, ви зменшуєте багато ризиків регресії за допомогою процесу, а не тестування. Більше того, питання насправді не стає питанням автоматизації (це лише інструмент, який ми будемо використовувати) - це просто питання тестування та ризику апетиту. Забудьте повністю про автоматизацію, які тести ви б застосували проти змін, щоб переконатися, що зміна не ввела проблем? Відповідь на це питання не змінюється від процесу тестування вручну до системи CI - єдиною перевагою є те, що багато з цих регресійних тестів, можливо, раніше були розроблені в попередніх функціональних можливостях, і CI рекомендує вам зробити менші, безпечніші зміни.
TLDR
Ваші тести повинні зменшити ризик зміни. Розгортання з дельтою нуля не несе ризику і тому не несе ризику. Зберігаючи ваші зміни невеликими, стає набагато простіше визначити тести, необхідні для їх перевірки - повторне використання автоматизації - це бонус.
Це той самий показник, що і при тестуванні продукту вручну.
Практично легко визначити ці зони з низькою довірою: якщо припустити, що ви відправляєте товар, то, мабуть, у вас є кілька посібників після закінчення роботи, що покращує впевненість у тому, що ви можете перевозити їх. Це сфери, які ви повинні автоматизувати, щоб покращити впевненість у самому автоматичному процесі.
Ваша автоматизація - це постійне зусилля. Він росте і вдосконалюється в міру вдосконалення вашого продукту. Дефект - це причина переосмислити свій код, а також переглядати CI. І сонячна сторона тут полягає в тому, що, оскільки довіра до самого продукту досяжна - довіра до автоматизації також досяжна.