wiremock tutorial introduction wiremock
Този уводен видео урок ще обясни характеристиките на Wiremock и как да стартирате Wiremock като самостоятелен сървър и като част от JUnit тестове:
В този урок ще разгледаме основните концепции и подробности около инструмента Wiremock. Може да се използва като самостоятелен HTTP сървър, както и в рамките на тестовете JUnit според изискванията.
Това е широко използван инструмент, тъй като е с отворен код и има голяма общност от сътрудници. Той попада в категорията инструменти за виртуализация на услуги.
Какво ще научите:
Какво е Wiremock?
С прости думи, Wiremock е подигравателна настройка за тестове за интеграция. Това е просто фалшив сървър, който е силно конфигурируем, за да върне очакван отговор за дадена заявка.
Той се използва широко по време на разработка и по-важното по време на тестване на интеграция, докато система или услуга разговаря с една или множество външни или вътрешни зависимости / услуги.
Нека се опитаме да разберем повече за интеграционното тестване като цяло и да разберем как Wiremock може да помогне да се преодолеят тези предизвикателства и да улесни живота ни.
Като цяло, когато дойде думата интеграция, това, което ни поразява, е интеграция от край до край между 2 комуникационни системи. Сега нека разгледаме това от гледна точка на тествано приложение, което използва някаква външна услуга, за да свърши работата.
Например, да предположим, че изграждаме приложение за система за онлайн пътуване или билети и имаме модул за проверка на статуса на PNR, който попада във външен API, предоставен от Indian Railways.
Сега, как можем да тестваме нашето приложение с външните API?
Има 2 начина да направите това:
- Първо, е подходът на Unit test, при който заглушаваме предоставения (или създаден в къщи) интерфейс, така че нашата система да тества / валидира заглушения или фалшив отговор дори преди да удари външния API. Това не е нищо друго освен Unit test, който се опитва да се подиграе на външна зависимост.
- Второ е тестване с някаква тестова среда (или действителната производствена среда) на външните зависимости. Има обаче няколко предизвикателства с този подход, споменати по-долу:
- Външните API системи може да не са винаги налични. т.е. ние сме силно зависими или зависими от външни системи и всеки престой там ще повлияе на нашите тестове и косвено процеса на разработка / пускане.
- На второ място, външните API могат да имат или не да имат тестова среда. Например, API за проверка на състоянието на PNR винаги може да изисква реални PNR номера за извличане и връщане на отговори.
- Много пъти има разходи за включване на API. Например, да предположим, че API за проверка на PNR таксува Rs 100 за всеки 1000 заявки. Тъй като тестовете за интеграция обикновено се изпълняват по време на всяка регресия (и по-голямата част от времето при всеки ангажимент), може да не е икономически ефективно решение да се удари такъв API, който ни струва дори за целите на тестването.
- Външен API не може да бъде конфигуриран да връща желания отговор. Дори ако е възможно, ще трябва да създадете много тестови данни, за да осигурите различни отговори за различни входове на заявките.
Например, искате да тествате сценарии за грешки, като API връща различни кодове на състоянието за различни типове данни. Сега, тъй като отговорът не е под наш контрол, ще трябва да създадем множество набори от данни, за да потвърдим различни възможни сценарии или резултати.
Нека разберем тези понятия с помощта на диаграмата по-долу.
Тук сравняваме двата подхода за тестване на интеграцията, т.е. без фалшив сървър, използващ действително изпълнение на външната зависимост, и с помощта на фалшив сървър (Wiremock), който се подиграва на отговорите на получените заявки за зависимостта.
В последния случай той значително намалява зависимостта и разчита на действителното изпълнение на зависимостта и дава много възможности за конфигуриране, без да прави компромис с качеството и графиците за доставка.
Как Wiremock отговаря на дадена заявка?
Както знаем, Wiremock е програмен Mock сървър, начинът, по който отговаря на дадена заявка, е чрез съхраняване на всички съответни съпоставяния (или подигравани отговори) в папка, наречена „mappings“
Има компонент за съвпадение на Wiremock, който съпоставя входящите заявки със съхранените съпоставяния и ако се върне успешно съвпадение, първото такова съвпадение се връща като отговор на дадената заявка.
В случай, че използвате самостоятелната версия на Wiremock, след като стартирате сървър Wiremock, ще видите папката за съпоставяне, която ще бъде създадена в директорията за инсталиране / буркан на Wiremock.
Видео урок: Въведение в Wiremock Tool
въпроси и отговори за интервю за разработчици на Java
Как да използвам Wiremock?
Сега нека видим как можем да използваме този инструмент с нашите тестове за интеграция.
Може да се използва по следните начини.
Самостоятелен Wiremock сървър
Като самостоятелен сървър можете просто да създадете просто Java приложение с зависимост Maven / Gradle за Wiremock и да го запазите като работещ процес.
Това е добра алтернатива, когато искате да хоствате своя самостоятелен сървър на някаква машина и да го използвате като един подигравателен сървър за целия проект или екип. В самостоятелен режим този инструмент също може да бъде изпълнен, като изтеглите наличния самостоятелен буркан тук и просто пуснете буркана.
Например, да предположим, че искате да разположите своя самостоятелен екземпляр на Wiremock на някакъв сървър в облак или локален сървър, тогава можете просто да стартирате този буркан и да използвате системния IP, за да го използвате като хоствана услуга.
Нека да видим някои стъпки за стартиране на това в самостоятелен режим (и конфигуриране на различни неща като портове, картографиране на папки и т.н.)
# 1) Стартирайте Wiremock jar от терминала (или командния ред за потребители на Windows) като всеки друг JAR файл (от директорията за инсталиране на jarmo на Wiremock).
java -jar wiremock-standalone-2.25.1.jar # две) По подразбиране Wiremock работи на localhost: 8080 (ако портът е безплатен за използване, тогава горната команда ще стартира сървъра Wiremock в самостоятелен режим) и ще видите изхода, както е показано по-долу.
# 3) След като сървърът стартира, можете да посетите всеки URL на localhost: 8080
Например, http: // localhost: 8080 / get / user / 1 - Тъй като в момента не се задават подигравки, ще получите отговор, както е показано по-долу.
# 4) Сега нека опитаме да настроим обикновен шут / макет за този URL и да опитаме да го върнем отново. След това ще потвърдим, че удрянето на същия URL адрес сега връща подигравания или заглушен отговор.
curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is!
' }}' http://localhost:8080/__admin/mappings/newНека първо се опитаме да разберем тази CURL заявка:
- Правим заявка CURL POST към http: // localhost: 8080 / __ admin / mappings / new - Сега това е мястото, където всички съпоставяния ще бъдат съхранени за сървъра Wiremock, който изпълнихме / стартирахме чрез JAR файла.
- В заявката Curl дефинираме параметри на заявката като - URL и метод на заявка, заедно с тялото на отговора в раздел „отговор“. Това просто означава, че всеки път, когато GET заявка влезе с URL / get / user / 1, след това отговорете с посоченото тяло на отговора.
# 5) След като е зададен заглушеният отговор (с помощта на горната заявка за къдрене), тогава можем да опитаме да натиснем URL адреса и да видим дали получаваме обратно загърнатия отговор от Wiremock.
Нека се опитаме да натиснем този URL в браузъра - http: // localhost: 8080 / get / user / 1
Ако картографирането е зададено успешно, трябва да получите отговор, както е показано по-долу:
Заедно с JUnit тестовете като JUnit Rule Configuration
Сървърът Wiremock може да се използва с тестове JUnit като настройка на правило JUnit. С това JUnit се грижи за жизнения цикъл на Wiremock, т.е. Wiremock стартира и спира.
кой сертификат за тестване на софтуер е най-добрият
Използва се най-вече в настройки, където искате да стартирате и спрете сървъра след всеки тест.
Това има свои собствени предимства да бъде изолиран и има висока степен на конфигурируемост, за разлика от самостоятелната настройка, при която множество хора могат в крайна сметка да използват един и същ сървър и да прекрачат взаимните мършави отговори.
Нека да видим работещ пример за този подход:
# 1) Създайте правило JUnit за сървъра Wiremock. Тази стъпка по същество е като стъпка за настройка на теста, където казваме на JUnit runner да създаде екземпляр на сървъра Wiremock преди всеки тест и да спре сървъра след всеки тест.
Това също означава, че JUnit runner ще се погрижи за стартиране и спиране на сървъра Wiremock, без изрично да го прави.
@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); # две) Сега ще напишем нашия тест, където първо ще създадем нашия клиент (използвайки okHttp), за да изпълним заявки срещу желаната крайна точка.
// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); # 3) Но тук можете да забележите, че все още не сме задали никакви заглушители, които да бъдат върнати за нашия екземпляр Wiremock. т. е. горният клиент ще поиска URL адрес http: // localhost: 8080 / test / abc, който няма конфигуриран stub. В този случай сървърът Wiremock ще върне 404 никакво съдържание.
# 4) Сега, за да зададем заглушка за горния URL адрес за нашия екземпляр на сървър Wiremock, ще трябва да извикаме статичните методи на заглушителя Wiremock, както е показано по-долу.
private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } Тук можете да видите, че сме използвали няколко статични метода като configureFor, stubFor и др. Всички тези методи са част от библиотеката на Wiremock Java. (Ще разгледаме подробно тези методи в следващия урок / раздели)
# 5) Сега с приключената стъпка за конфигуриране можем просто да изпълним заявката чрез клиент и да проверим отговора (в зависимост от това какво е конфигурирано за връщане на заглушителя през Wiremock)
За да обобщим, ето как би изглеждала цялата проба на кода:
public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } } Задължителни зависимости
Предлага се като:
- Самостоятелен JAR, съдържащ само зависимостта от Wiremock.
- Буркан за мазнини, съдържащ Wiremock и всички негови зависимости.
И двата вкуса се предлагат като зависимости Gradle и Maven. Повече подробности можете да намерите в официалното хранилище на Maven тук
Видео урок: Wiremock с тест JUnit
Заключение
В този урок разгледахме основните характеристики на Wiremock и видяхме как той може да се изпълнява като самостоятелен сървър и като част от тестовете JUnit, използвайки правилата на JUnit.
Ние също засегнахме накратко накратко и ще го разгледаме подробно в следващия урок.
СЛЕДВАЩ урок
Препоръчително четене
- Въведение в Micro Focus LoadRunner - Тестване на натоварване с LoadRunner Урок # 1
- Урок за Ngrok: Кратко въведение с инсталация и настройка
- Урок за TestNG: Въведение в TestNG Framework
- Въведение в Selenium WebDriver - Урок № 8 за селен
- Въведение в езика за програмиране на Java - видео урок
- Процес на въвеждане и инсталиране на Python
- Какво е Unix: Кратко въведение в Unix
- Урок за Neoload: Въведение, изтегляне и инсталиране на Neoload