introduction contract testing with examples
Този урок за тестване на договор обяснява какво е тестване по договор, управлявано от потребителя, как работи и защо трябва да го използвате във вашата стратегия за тестване:
Какво е тестване по договор?
Контролираното от потребителя тестване е форма на API тестване, която наистина позволява смяна наляво. Договорният инструмент, който използваме, е Pact.io и ще научим за това по-късно в тази серия уроци.
Тестването на договора е метод за проверка на интеграцията между две приложения независимо, за да се тества предаденото и да се види дали върнатото съвпада с „договора“.
Тестовете за поръчки се вписват добре в архитектурата на микросервиса, като работят в гъвкава обстановка. Следователно примерите ще се основават на опита, който сме натрупали по време на работа в тази среда.
Какво ще научите:
- Списък с уроци в тази поредица за тестване на договори
- Контролирано от потребителите тестване на договори
- Тестване по договор срещу тестване за интеграция
- Непрекъсната интеграция
- Заключение
Списък с уроци в тази поредица за тестване на договори
Урок # 1: Въведение в договорното тестване с примери (Този урок)
Урок # 2: Как да напиша тест за потребителски пакт в JavaScript
Урок № 3: Как да публикувам договор за договор с брокер
Урок № 4: Проверете договорния договор и непрекъснатото внедряване с Pact CLI
Контролирано от потребителите тестване на договори
Отправната точка е вашата документация за API, която формира договора за вашите тестове, като в този момент обикновено екипите за разработки вземат документа на API и се разработват срещу wiki документа (или в който и формат да се намира във вашата организация, като Word Document).
Например, уеб приложение, при което интерфейсът се разработва от Team Krypton, а API се разработва от Team Thoron. Проектът започва с начална среща, където изискванията са представени и договорени между екипите.
Всеки екип взема изискванията и започва да създава изоставането, като прецизира историите. Разработката започва и в двата отбора следвайки потребителските истории, тестването за интеграция е оставено за по-късни спринтове. Тъй като екипът Krypton намира допълнителни изисквания, свързани със сценарии за грешки, документацията на API се актуализира съответно.
Тест случаи се добавят от Team Thoron, свързани с актуализираните сценарии въз основа на документацията.
Вече можем да видим няколко недостатъка в този процес и добавих още няколко за късмет:
- Промените в документите на API може да не се предават ефективно.
- Екипът от преден край заглушава обслужването отзад и обратно.
- Back-end екипът създава тестови случаи за интеграция въз основа на документация.
- Интеграционната среда е първият път, когато се тества пълната интеграция.
- Различна версия на API за среда за интеграция срещу производство.
Контролираното от потребителите тестване на договори има две страни, т.е.потребителят и доставчикът. Тук традиционното мислене за тестване в микроуслуги се преобръща.
The Консуматор е куратор на сценариите, включително заявката и очаквания отговор. Това ви позволява да следвате Закон на леглото което диктува, че трябва да бъдете гъвкави в това, което API може да приеме, но консервативни в изпратеното. Позовавайки се на недостатъци №. 1, 3 и 4, промените в документацията се управляват от потребителя.
Например, в случай, че Team Thoron променя низово поле, за да не приема нулеви стойности, потребителските тестове няма да отразят промяната и следователно ще се провалят. Или поне докато промените не са направени в Team Krypton.
(изображение източник )
The Доставчик проверява предоставените от потребителя сценарии спрямо тяхната „dev“ среда. Това позволява на вашите микроуслуги да налагат Паралелна промяна което гласи, че трябва да разширите функционалността на API, последвано от мигриране към нова версия. Позовавайки се на недостатък №. 2, мъничките, които обикновено се създават от екипите от задния край за техните собствени изисквания за тестване, вече могат да се основават на потребителските сценарии Pact Stub Server .
Обвързващият елемент на двете страни е „договорът“, който трябва да бъде споделен между екипите. Пактът предоставя платформа, която позволява споделянето на договори, наречени Пакт брокер (предлага се като управлявана услуга с Pactflow.io ).
The Брокер съхранява резултатите от потребителските сценарии. След това договорът се съхранява в брокера заедно с версията на API. Това позволява тестване срещу множество версии на API, като по този начин съвместимостта може да бъде потвърдена преди пускането, както е подчертано в недостатък № 5.
Допълнителна полза за Pact Broker в старите платформи е видимостта на потребителите. Не всички потребители са известни на авторите на API, особено не е как се консумират.
По-конкретно позовавайки се на събитие, при което се поддържат две версии на API, има проблем с данни във версия 1 (V1), при който API причинява мръсни данни в базата данни.
Промяната е внедрена във V1 на API и е насочена към производство, но потребителят разчита на формата, който причинява проблема с данните, като по този начин нарушава интеграцията им с API.
Как работи
Примерът по-горе показва потока за удостоверяване, уеб услугата изисква потребителите да удостоверяват, за да имат достъп до чувствителни данни. Уеб услугата изпраща заявка до API за генериране на маркер, използвайки потребителско име и парола. API връща токен на носител, който се добавя към заявката за данни като заглавка за удостоверяване.
Потребителският тест конструира POST заявка за маркер, като предаде тялото с потребителско име и парола.
По време на теста се завърта фалшив сървър, който потвърждава заявката, която конструирате, заедно с очаквания отговор, който в този пример включва стойността за маркера.
Резултатът от потребителския тест генерира файл с договор за договор. Това ще се съхранява в брокер на пакта като версия 1.
След това доставчикът изтегля версия 1 от посредника на пакта и възпроизвежда тази заявка срещу тяхната локална среда, като проверява дали заявката и отговорът съвпадат с изискванията на потребителите.
Роли и отговорности
Осигуряване на качеството (QA) / тестер: Създаване на договори с помощта на Pact.io и работа с BA за генериране на тестови сценарии.
Разработчик: Сдвояване с QA за създаване на тестове и подпомагане на обгръщането на API за внедряване в непрекъсната интеграция (CI).
Бизнес анализатор (BA): Генериране на сценарии и работа с архитекта за проверка на засегнатите страни.
Архитект на решения (Възможно е да не съществува във вашата организация): Действие на промените в API и координиране с BA относно внедряването, също така съобщаване на промени на потребителите (използвайки Pact Broker, за да разберете кого може да засяга).
Управление на изданието: (Да, знам, че е старомоден, но все още съществува в моя свят): Изпълнен с увереност, че промените ще бъдат пуснати успешно поради покритие на тестване на договора.
Целият екип: Проверете резултатите, за да определите дали изданията могат да бъдат пуснати в производство с инструмента Pact CLI, Мога ли да разположа .
Тестване по договор срещу тестване за интеграция
Трябва да съществува тестване за интеграция, за да се провери дали системата работи преди промоцията в производствената среда, но сценариите могат да бъдат значително намалени.
Въздействието на това може да бъде:
- По-бърза обратна връзка преди пускане в интеграционната среда.
- По-малко разчитане на стабилността на интеграционната среда.
- По-малко среди, поддържащи множество версии на API.
- Намалени случаи на нестабилна среда поради проблеми с интеграцията.
| Интеграция | Договор | |
|---|---|---|
| Очевидно е да се определи неуспех | Много слоеве | Много лесно |
| API конфигурация | Да | Недей |
| Проверки за внедряване | Да | Недей |
| Версия на API | Да | Да |
| Локално отстраняване на грешки | Недей | Да |
| Проблемите на околната среда | Да | Недей |
| Време за обратна връзка | Бавен | Бърз |
Първо, тестването по договор не заменя интеграционното тестване. Но вероятно може да замени някои от вашите съществуващи сценарии за тестване на интеграция, да се измести наляво и да осигури по-бърза обратна връзка за жизнения цикъл на разработката на софтуера.
При интеграционното тестване ще проверявате контекста, в който API живее, като архитектурата на околната среда, процеса на внедряване и т.н.
Следователно искате да стартирате основните тестови сценарии, които да потвърдят конфигурацията, например, крайната точка за проверка на състоянието за версията на api. Също така доказване дали разполагането е било успешно чрез връщане на отговор 200.
При тестване на договори вие тествате спецификите на API, което включва крайни случаи, свързани със структурата на API, съдържание (напр. Стойности на полета, ключове съществуват) и отговори на грешки. Например, обработва ли API нулевите стойности или те са премахнати от отговора на API (друг реален пример).
Някои предимства (ако вече не сте продадени)
По-долу са изброени някои от предимствата, които трябва да се използват при продажбата на тестване на договори за по-широкия бизнес:
- По-бързо внедряване на софтуер
- Единствен източник на истина
- Видимост на всички потребители
- Лесно тестване срещу различни версии на API.
често задавани въпроси
Някои често срещани въпроси, докато се опитвате да убедите хората да приемат тестване по договор, включват:
В # 1) Вече имаме 100% покритие на теста, така че нямаме нужда от него.
Отговор: Е, това е невъзможно, но тестването по договор има много други предимства, освен просто покритие на теста.
В # 2) Отговорността на Solution Architect е да съобщава промените в API.
Отговор: Качеството е отговорност на целия екип.
В # 3) Защо създаваме тестови сценарии за екипа на API?
Отговор: Екипът на API не знае как работи уеб услугата, така че защо трябва да носи отговорност.
В # 4) Нашите тестове от край до край обхващат целия поток от началото до края, включително други точки на интеграция.
Отговор: Точно защо разделяме тестовете, за да тестваме едно нещо и не е ваша отговорност да тествате потока от край до край на системата, която не знаете как работи.
В # 5) В хранилището на кой екип тестовете живеят?
Отговор: И двете. Потребителят в тяхното хранилище и Доставчикът в тяхното. Тогава в централната точка договорът живее извън нито един от тях.
Аргументи
най-добрият безплатен софтуер за възстановяване на данни windows 10
Това са аргументите, срещу които ни е трудно да спорим, когато става въпрос за преминаване към договор към тест:
- Вече съществува документация на Swagger, която може да се използва за генериране на тестове за интеграция.
- Екипите притежават услуги отпред и отзад и с ефективен механизъм за промени в API.
Непрекъсната интеграция
Как това се вписва във вашия пакет за непрекъсната интеграция? Желаното място за тестване по договор е да използвате вашите модулни тестове.
Потребителските тестове завъртат фалшив сървър, който не изисква външни зависимости извън теста.
Тестовете на доставчици изискват екземпляр на API, поради което локалният API може да бъде обвит с помощта на тестов сървър в паметта . Ако обаче не е лесно да увиете вашия API локално, заобиколно решение, което използвахме преди, е, когато завъртяхме среда и внедрихме кода в тази среда като част от автоматичните проверки на искането за изтегляне.
(изображение източник )
Заключение
В този урок научихме какво означава тестване на договор и как изглежда в инфраструктурата на микросервиз и видяхме как изглежда в реалния пример.
Научени са уроци за това как тестването по договор може да ви помогне да преместите интеграционното тестване наляво. Освен това видяхме как това може да намали разходите за вашата организация, като намали времето за обратна връзка, свързано с проблеми с интеграцията.
Изпитването по договор е не само инструмент за техническо тестване, той налага сътрудничеството на екипите за разработка, като съобщава промените и насърчава тестването като едно цяло. Като цяло това трябва да е предпоставка за всеки, който иска да премине към Непрекъснато внедряване.
СЛЕДВАЩ урок
Препоръчително четене
- Как да напиша тест за потребителски пакт в JavaScript
- Проверете договорния договор и непрекъснатото внедряване с Pact CLI
- Как да публикувам договор за договор с брокер
- Непрекъснат процес на интеграция: Как да подобрим качеството на софтуера и да намалим риска
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване
- Какво е тестване на интеграция (урок с пример за тестване на интеграция)
- Топ 10 Инструменти за тестване на интеграция за писане на тестове за интеграция
- Непрекъснато внедряване в DevOps