Środowisko testowe pod rest-a

ŚRODOWISKO TESTOWE POD REST’A

Piotr MisiugaTest Developer

AGENDA

1. REST API 2. Framework Rest-Assured 3. Maven – wprowadzenie 4. Embedded Tomcat i Embedded

ElasticSearch 5. SonarQube i pokrycie testów

integracyjnych z JaCoCo

REST API

Representational State Transfer – styl architektoniczny dla projektowania aplikacji rozproszonych

Założenia: Architektura klient-serwer Bezstanowość (cache) Jednolity interfejs dostępu

Jednolity interfejs: Jednolita identyfikacja / adresacja zasobów Manipulacja zasobami poprzez ich reprezentacje Bezstanowa komunikacja (serwer nie tworzy sesji)

REST API

Styl architektury dla projektowania aplikacji sieciowych

http://www.codeproject.com/Articles/426769/Creating-a-REST-service-using-ASP-NET-Web-API

REST API

Zasoby jako źródła danych URI – nazwa, która identyfikuje zasób

Np. http://myserver/tasks Np. http://myserver/tasks/12345


http://myserver/tasks

http://myserver/tasks/12345

REST API

Każdy zasób posiada reprezentację Reprezentacje dodatkowo mogą zawierać

metadane


ARCHITEKTURA TESTÓW

REST API – JEDNOLITY INTERFEJSMETODY

GET - odczytywanie danych POST - wstawianie/edycja danych PUT – wstawianie/edycja danych DELETE - usuwanie danych

REST API – METODA GET

REST API – METODA GET

Filtrowanie zapytań

REST API – METODA POST

REST API – METODY CRUD ≠ HTTP?

CRUD HTTP

Create POST

Read GET

Update PUT

Delete DELETE

POST VS. PUT

Idempotentność – koncepcja specyfikacji HTTP.

Requesty, które posiadają tę cechę będą zakończone niezmiennym stanem po stronie serwera, niezależnie od tego ile razy zostaną wykonane.

GET, HEAD, PUT, DELETE są idempotentne

POST VS. PUT OPERACJA CREATE

POST:- zalecana metoda- używamy, gdy nie znamy identyfikatora tworzonego zasobu (generowany jest po stronie serwera)- w odpowiedzi otrzymujemy status „201 Created” oraz położenie(identyfikator) nowostworzonego zasobu

POST VS. PUT OPERACJA CREATE

PUT:- musimy podać identyfikator- używane w systemach, gdzie identyfikator generowany jest po stronie klienta-Wstawia zasób zastępując całkowicie to co istnieje pod danym URL, dlatego wymaga podania wszystkich wartości

POST VS. PUT OPERACJA UPDATE

POST:- w ciele możemy podać wszystkie pola lub tylko niektóre z nich- nie jest idempotentna, bezpieczna

POST VS. PUT OPERACJA UPDATE

PUT:- w ciele musimy podać wszystkie pola(wartości)- jest idempotentna

PODSUMOWANIE

ZasóbPOST

(create)GET

(read)PUT

(update)DELETE(delete)

/customers

201(Created), Zostaje

stworzony nowy klient z

wygenerowanym ID

200(OK),Pobranie listy

klientów

404(Not Found), chyba, że edytujemy całą kolekcję

404(Not Found), chyba, że usuwamy całą kolekcję

/customers/{id}

404(Not Found)Pobranie klienta

o ID {id}

200(OK) lub 204(No

Content). Zwraca klienta jeśli istnieje.

404(Not Found) Jeśli nie istnieje

zwraca błąd

200(OK) usuwa klienta o ID

{id}. 404(Not Found)Jeśli nie istnieje

zwraca błąd.

NARZĘDZIA DO TESTOWANIA REST’A

curl

Python:-urllib2-requests-rester

Java:-Rest-assured + awaitility

AGENDA




REST-ASSURED

Łatwy w użyciu DSL oparty na Javie Gherkin syntax (given(), when(), then()) Automatyczne mapowanie(JAX-B dla XML jak i

Jackson lub Gson dla JSON) Walidacja Xpath (XMLPath) Walidacja JSONpath (JSONPath) Reużywalność specyfikacji

REST-ASSURED

REST-ASSURED

Wymagania:-JDK >= 1.6-Maven

Instalacja za pomocą maven’a:

KONFIGURACJA REST-ASSURED

WALIDACJA JSON’A

WALIDACJA JSON’A II

WALIDACJA JSON’A VS. JSON SCHEMA

WALIDACJA JSON VS. JSON SCHEMA

GROOVY CLOSURES W JSONPATH

WALIDACJA XML

WALIDACJA XML – OBSŁUGA XPATH

WALIDACJA XML WYKORZYSTUJĄC XSD SCHEMA

PRZESYŁANIE PARAMETRÓW, WALIDACJA STATUSU I CONTENT-TYPE

PROSTE UWIERZYTELNIANIE

USTAWIANIE NAGŁÓWKÓW

TESTOWANIE NAGŁÓWKÓW

TESTOWANIE DOSTĘPU PRZY UŻYCIU COOKIES

WALIDACJA ZA POMOCĄ COOKIES

WIELOKROTNE WYKORZYSTANIE SPECYFIKACJI

AWAITILITY – BIBLIOTEKA DO TESTOWANIA ASYNCHRONICZNYCH SYSTEMÓW

AWAITILITY – BIBLIOTEKA DO TESTOWANIA ASYNCHRONICZNYCH SYSTEMÓW

Instalacja

Przykład użycia

AWAITILITY + REST-ASSURED

AGENDA




MAVEN – WPROWADZENIE

Budowanie oprogramowania przy użyciu maven’a ma zakończyć się osiągnięciem wybranego celu

Cele definiowane są przez wtyczki (plugins) Cele mogą być wywoływane w różnych

fazach cyklu życia projektu Projekt mavenowy definiuje się poprzez

stworzenie i utrzymywanie pliku pom.xml (Project Object Model)

POM zawiera elementy definiujące projekt, jego strukturę, sposób budowania i zależności

PRZYKŁADOWY POM.XML

DOMYŚLNY CYKL ŻYCIA PROJEKTU Fazy domyślnego cyklu życia projektu:

- validate - sprawdza poprawność projektu

- compile - kompiluje kod źródłowy;

- test - wykonuje testy jednostkowe;

- package - pakuje skompilowany kod w paczki dystrybucyjne (np. Jar, war);

- integration-test – deployuje paczkę w środowisku testów integracyjnych;

- verify - sprawdza poprawność paczki;

- install - umieszcza paczkę w lokalnym repozytorium aby mogła być używana przez inne moduły;

- deploy - umieszcza (publikuje) paczkę w zdalnym repozytorium.

DODATKOWE CYKLE ŻYCIA

clean – czyści wynik działania wcześniejszych buildów (folder target)

site – generuje dokumentację projektu

PLUGINY

Wywołanie celów zdefiniowanych w pluginach za pomocą komendy mvn [plugin]:[goal]

mvn compile:compile

ZALEŻNOŚCI

MAVEN - DZIAŁANIE

POWIĄZANIA POMIĘDZY POM-AMI

1. Dziedziczenie projektów

Co jest dziedziczone?- zależności- pluginy- konfiguracje

2. Agregacja – projekty wielomodułowe

DEFINIOWANIE USTAWIEŃ

Możliwość definiowania zmiennych lub zarządzania zmiennymi:- projektu ${project.version}

- środowiskowymi ${env.JAVA_HOME} - systemowymi ${java.version}

PROFILE

Umożliwiają zbudowanie projektu w różnych środowiskach np. QA, DEV, PROD

PROFILE

Aktywacja profilu mvn [plugin]:[goal]-P[profil]

AGENDA




INTEGRACYJNE TESTY NA EMBEDOWANYM TOMCACIE

Cel jaki chcemy uzyskać to:1. Uruchomić aplikację, którą chcemy testować na wtyczce Apache Maven Tomcat 72. Uruchomić testy posiadające przyrostek IntegrationTest3. Po testach wyłączyć serwer


Wtyczka Surefire odpowiada za uruchomienie testów JUnit w fazie test

Musimy wyłączyć testy integracyjne z tej fazy


Wtyczka Failsafe odpowiada za uruchomienie testów integracyjnych JUnit w fazie integration-test

Dodajemy testy integracyjne i aktywujemy plugin

WIELOMODUŁOWY PROJEKT NA EMBEDDED TOMCAT

Problem: Celem jest przetestowanie aplikacji zanim trafi do repozytorium


Rozwiązanie: -ustawienie zmiennych w parent pom.xml


Ustawienie ścieżek do projektów z zasobami w child-pomach

Moduł z testami aplikacji moduleA

Moduł z testami aplikacji moduleB

ELASTICSEARCH – KTÓRTKIE WPROWADZENIE

Czym jest ES? Bazą danych dokumentów rozproszonych

Darmowym (open-source) silnikiem wyszukiwania w czasie rzeczywistym

Narzędziem do analizy

RESTowym serwisem

Nie przejmuje się schemą

ELASTICSEARCH – JAKO BAZA NOSQL

MySQL ElasticSearch

Baza danych Index

Tabela Typ (Type)

Wiersz Dokument (Document)

Kolumna Pole (Field)

Schema Mapowanie (Mapping)

Index Wszystko jest indeksowane

SQL DSL zapytań

SELECT * FROM table… GET http://

UPDATE table SET … PUT http://

EMBEDDED ELASTICSEARCH – POTRZEBNA TERMINOLOGIA

Node – instancja elasticsearch (proces javowy), zwykle jeden node uruchomiony jest na jednej maszynie. Odpowiada za przechowanie danych, dodawanie i usuwanie indeksów

Cluster – grupa node’ów z tym samym cluster.name, które współdzielą dane i zapewniają działanie i skalolwalność. Pojedynczy node może tworzyć cluster

Mapping – proces definiowania struktury typu w indeksie.

Client– klient javy, który umożliwia wysyłanie requestów do node’a w clusterze.

INTEGRACYJNE TESTY W OPARCIU O EMBEDDED ELASTICSEARCH PROCEDURA

Tworzymy node’a Tworzymy indeks i definiujemy mapowanie Dodajemy dokumenty o danym typie Uruchamiamy naszego embedded

elasticsearch’a przed uruchomieniem testów

EMBEDDED ELASTICSEARCH – TWORZENIE NODE’A

PRZYKŁADOWY MAPPING

EMBEDDED ELASTICSEARCH – DODAWANIE MAPPINGU, TWORZENIE INDEXU

EMBEDDED ELASTICSEARCH – DODAWANIE DOKUMENTÓW

INTEGRACYJNE TESTY W OPARCIU O EMBEDDED ELASTICSEARCH

Piszemy prosty mavenowy plugin dla embedded elasticsearch’a.

AGENDA




SONARQUBE – NARZĘDZIE DO ZARZĄDZANIA JAKOŚCIĄ KODU

Sonar analizuje kod w siedmiu wymiarach:

duplikacja kodu standardy kodowania (konwencje) testy jednostkowe kompleksowość potencjalne błędy komentarze architektura

SONARQUBE - DASHBOARD

POKRYCIE KODU

Co to jest pokrycie kodu?

Miara wykorzystywana przy testowaniu oprogramowania

Opisuje w jakim stopniu program został sprawdzony przez testy

Zazwyczaj wykorzystywane przy określaniu ‘skuteczności’ testów jednostkowych (integracyjnych)

Dla większości języków istnieją zestawy narzędzia do testowania / pomiaru pokrycia

Pokrycie możemy mierzyć według różnych kryteriów

JACOCO – NARZĘDZIE UMOŻLIWIAJĄCE POMIAR POKRYCIA KODU W ŚRODOWISKACH JVM

JaCoCo

Analizuje pokrycie instrukcji (C0), gałęzi (C1), linii, metod, typów, powtarzalności kodu

Wspiera różne języki JVM Zintegrowane z wieloma popularnymi

narzędziami w tym SonarQube, Maven Przeprowadza instrumentacje bajt kodu „w locie”

(tym wyróżnia się spośród konkurencji) http://www.eclemma.org/jacoco/

ANALIZA POKRYCIA KODU PRZEZ TESTY INTEGRACYJNE – SONAR I JACOCO

1. Konfiguracja agenta JaCoCo i przypisanie go do JVM, na której uruchamiane są testy integracyjne. Konfiguracja możliwa jest poprzez linię komend lub poprzez JaCoCo Maven plugin

2. Uruchomienie integracyjnych testów. Na koniec agent JaCoCo generuje raport pokrycia kodu w miejscu, które ustawiliśmy w kroku 1.

3. Konfiguracja SonarQube, by używał wygenerowanego raportu

4. Po uruchomieniu analizy Sonar’a generuje się pokrycie kodu przez testy integracyjne

KONFIGURACJA AGENTA JACOCO – JACOCO MAVEN PLUGIN

Dodajemy jacoco-maven-plugin do naszego projektu

Konfigurujemy plugin

KONFIGURACJA FAILSAFE-PLUGIN

Konfigurujemy failsafe plugin, gdyż to on jest odpowiedzialny za uruchomienie testów integracyjnych

KONFIGURACJA SONARQUBE

W pliku sonar-project.properties

sonar.jacoco.itReportPath=target/jacoco-it.exec

W sonar-maven-plugin

<sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin> <sonar.jacoco.itReportPath>target/jacoco-it.exec</

sonar.jacoco.itReportPath>


Problem – Embedded Tomcat

Niestety wtyczka tomcat7-maven-plugin nie potrafi „skonsumować” / skorzystać z argLine’a, z którego korzysta failsafe plugin (Jetty potrafi)

Rozwiązanie:

Przekazanie argumentów VM do konfiguracji build’a


Wynik po uruchomieniu testów integracyjnych, a następnie analizy SonarQube’a

DZIĘKUJĘ ZA UWAGĘ!

Środowisko testowe pod rest-a

Technology