Відповідно до правил тестових модулів TDD написані перед виробничим кодом, а як щодо тестів інтеграції, що здійснюють взаємодію між конкретними (не макетними) дротовими об'єктами?
Чи повинні вони бути записані перед одиничними тестами або після коду виробництва лише для перевірки "проводки"?
Зауважте, що я кажу не про прийняття чи функціональні тести, а про тести інтеграції нижчого рівня.
Відповіді:
Книга Rspec , серед інших ресурсів BDD, пропонує такий цикл:
По суті, процес:
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
Відмова: Я не сумніваюся, що це призводить до найкращого коду та продукту, але це може зайняти багато часу. Існують всілякі труднощі навколо даних та детермінізму, якщо говорити про те, що тести на інтеграцію завжди повинні проходити. Це не доречно за будь-яких обставин; іноді просто потрібно дістати речі з дверей.
Але, маючи на увазі ідеальний процес, це чудово. Це дає точку, з якої можна піти на компроміс.
Реальний проект показав мені, що писати одиничні тести неможливо, і тоді інтеграція і навіть протилежний напрямок неправильні :-) Отже, я зазвичай пишу одиничні тести разом з інтеграційними.
Чому? Дозвольте мені написати, як я бачу обидва типи тестів:
Тестові одиниці - Окрім Вікіпедії та всієї відомої інформації, одиничні тести допомагають вам звузити дизайн , покращити модель, відносини. Потік простий: як тільки ви починаєте вводити новий проект / новий компонент, більшу частину часу ви створюєте певний PoC . Коли ви закінчите, у вас завжди є довгі методи, довгі заняття, неузгоджені методи та заняття тощо.
Експериментальні тести допоможуть вам усунути ці проблеми, коли ви робите реальне тестування одиниць, використовуючи макети (без залежності від інших компонентів), описані вище класи не піддаються перевірки. Основна ознака нестійкого коду - велика насмішкова частина тестів, тому що ви змушені знущатися над багатьма залежностями (або ситуаціями)
Інтеграційні тести - правильні та робочі тести говорять про те, що ваш новий компонент (або компоненти) працюють разом або з іншими компонентами - це звичайне визначення. Я виявив, що тести інтеграції здебільшого допомагають вам визначити потік, як використовувати ваш компонент із боку споживача .
Це дійсно важливо, оскільки іноді вам кажуть, що ваш API не має сенсу ззовні.
Ну, а що станеться, коли я потім написав одиничні тести та інтеграційні тести?
Я отримав гарні класи, чіткий дизайн, хороший конструктор, короткі та узгоджені методи, готовий IoC тощо. Після того, як я даю свій клас / API якомусь споживачеві, наприклад розробнику з інтеграції чи команді GUI, він не зміг використати мій API, як здається нелогічним , дивно. Він просто розгубився. Тому я відремонтував API відповідно до його точки зору, але це також вимагало переписати багато тестів, тому що мене підштовхували до зміни методів, а іноді навіть до того, як використовувати API.
Ну, а що станеться, коли я потім написав інтеграційні тести та одиничні тести?
Я отримав точний потік, хорошу зручність використання. У мене також є великі класи, некогерентний код, відсутність журналів, довгі методи. Код спагетті
Яка моя порада?
Я дізнався наступний потік:
Зауважте, що я зробив невелику презентацію про тестування блоку / інтеграції, див. Слайд №21, де описаний кістяк.
Тести блоку використовуються для тестування найменшого можливого біта програмного забезпечення в додатку та для перевірки його функціональності. Кожен блок перевіряється окремо перед об'єднанням їх у частини або більші компоненти програми.
Ось де
проводяться інтеграційні тести :
вони випробовують ці новостворені деталі, які складаються з попередньо перевірених підрозділів під час встановлення цих деталей разом. Найкращим випадком було б написати тести в цей момент під час написання самої заявки.
Я схильний розглядати інтеграційні тести як дуже схожі на одиничні тести. У зв'язку з цим я розглядаю підмножину коду як чорну скриньку. Тож інтеграційні тести - просто більша скринька.
Я вважаю за краще писати їх перед виробничим кодом. Це має перевагу в тому, щоб допомогти мені запам'ятати, які твори я ще не провів, або що я трохи змінив деталь у взаємодії об'єктів.
Крім тестів на прийняття, я схильний писати лише тести інтеграції на межах програми, щоб переконатися, що вона добре інтегрується із сторонніми системами або компонентами.
Ідея полягає у створенні адаптерних об’єктів, які перекладаються з того, як третя сторона розмовляє з тим, що потрібно вашій програмі, і перевірити цих перекладачів на реальну зовнішню систему. Незалежно від того, чи робите ви тест перший чи тестовий останній, я вважаю менш важливим, ніж для звичайних тестових одиниць
Розуміння дизайну, що надається TDD, не має великого значення, оскільки дизайн досить відомий заздалегідь, і зазвичай немає нічого страшного складного, ви просто збираєте речі з однієї системи в іншу.
Залежно від модуля / системи, з якою ви хочете вирішити, це може зажадати великого дослідження, налаштування конфігурації, підготовки зразків даних, що вимагає часу і не дуже добре вписується в короткий цикл зворотного зв'язку TDD.
Однак, якщо вам справді комфортніше поступово будувати адаптер за невеликі безпечні кроки, я напевно рекомендую пройти тест спочатку, це не може зашкодити.
Ви можете знайти приклади такого підходу тут: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (шостий абзац) http://blog.8thlight.com/eric- Сміт / 2011/10/27 / thats not not your.html
Тому я збирався прийняти першу відповідь, але вона була видалена.
Підсумовуючи це
за заданою ітерацією:
Пам’ятайте про тестування інтеграції в той час, як 1 і 2 гарантують перевірку на рівні інтеграції.
Інтеграційні тести не обов'язково записуються в кінці на етапі 3, вони можуть бути частково записані між кроком 1 і 2.
Блок тестує дискретні блоки коду у вашому проекті.
Інтеграційні тести перевіряють, як ваш код взаємодіє з іншим кодом: іншими словами, вони перевіряють інтерфейс вашого коду.
Пишіть одиничні тести при розробці коду за інтерфейсом.
Пишіть тести інтеграції при розробці інтерфейсу або будь-якого коду, який реалізує інтерфейс.
Це означає, що ви іноді пишете інтеграційні тести дуже пізно в проекті, оскільки більша частина роботи стоїть за інтерфейсом: наприклад, компілятор, певна веб-служба, яка реалізує декілька шарів логіки або .. щось, що передбачає багато внутрішня логіка.
Однак якщо ви впроваджуєте набір REST-послуг або переробляєте модель даних та додаєте підтримку транзакцій XA, ви майже відразу розпочнете розробку інтеграційних тестів, оскільки більша частина вашої роботи зосереджена на інтерфейсі, будь то API REST або як програма використовує модель даних.