| Tytuł: | Testy Kontraktowe na platformie Java i Pact |
| Kod: | Arch-ct |
| Kategoria: | Architektura systemów i aplikacji |
| Forma: | 50% wykłady / 50% warsztaty |
| Czas trwania: | 3 dni |
| Zapisy: |
Indywidualne zamówienie i dopasowanie dla grupy. |
| Logistyka: |
W siedzibie klienta lub w innym dowolnym miejscu. |
Celem szkolenia jest nauka wykorzystania testów kontraktowych do zapełnienia luki w całości strategii testowania mikroserwisów aby zredukować koszt integracji i testów manualnych oraz automatycznych na środowiskach wdrożeniowych.
Uczestnikami szkolenia są programiści mierzący się ze złożonością testowania integracji i bezpieczeństwa wdrożeń w architekturze mikroserwisowej, pragnący poszerzyć swoją wiedzę o sprawdzone strategie i wzorce. Warsztat systematyzuje rozbudowane zagadnienie, daje praktyczne wsparcie przy wdrażaniu i utrzymaniu testów kontraktowych.
Mnogość ruchomych elementów i skomplikowanie architektury mikroserwisów powoduje że znane dotąd strategie pracy z kodem i testami wymagają dedykowanego podejścia. Takiego które zagwarantuje wysoką jakość produktu i sprawną współpracę zespołów nie powiększając jednocześnie kosztu wytworzenia i utrzymania zarówno dla testów wewnątrz pojedynczego mikroserwisu jak i kontraktów oraz interakcji pomiędzy nimi.
- zrozumieją potrzeby i korzyści oraz konsekwencje wdrożenia testów kontraktowych
- poznają receptury i kryteria doboru zakresu oraz szczegółowości testowanego kontraktu
- rozpoznają wzorce i antywzorce spotykane na każdym poziomie testów kontraktowych
Uczestnicy szkolenia:
Wyróżniki szkolenia
- Zagadnienia architektury systemu i testów gwarantujących bezpieczeństwo wdrożeń
- Najlepsze wzorce i praktyki testów kontraktowych
- Aspekty strategii shift-left w testowaniu oprogramowania
Program Szkolenia
Program jest ramą w jakiej możemy się poruszać merytorycznie - program dla konkretnego szkolenia dedykowanego ustalamy z grupą na podstawie analizy przed-szkoleniowej.-
Testy kontraktowe w testowaniu mikroserwisów- Czym jest Architektura Mikroserwisów
- Odpowiedzialność serwisów i całego systemu
- Odniesienie poziomu testów do poziomu abstrakcji modelu C4
- Odpowiedzialność serwisów i całego systemu
- Złamanie kontraktu: Zyski i koszty rozpraszania
- Odpowiedzialność zespołów za serwisy i jakość / testy
- Wzorce integracji i kontraktów
- Komunikacja Synchroniczna i Asynchroniczna
- Różnicowanie rodzaju kontraktu między Producentem a konsumentem (OpenHost, Conformist, Consumer-Supplier)
- Różnicowanie wzorców komunikatów: Komendy, Zdarzenia i Kwerendy
- Komunikacja Synchroniczna i Asynchroniczna
- Czym jest Architektura Mikroserwisów
-
Testy kontraktowe dla Shift-left: Redukcja kosztu testów- Miejsce testów kontraktowych w piramidzie testowania
- Szybka pętla zwrotna
- Uzasadnienie i koszt dla testów kontraktowych
- Miejsce testów kontraktowych w piramidzie testowania
-
Wachlarz narzędzi zapewniających zgodność kontraktów- Dedykowane narzędzia: Pact i Spring Cloud Contract
- Pozostałe gwarantujące podzbiór funkcjonalności: SDK, JSON Schema, scalanie, stabilizowanie, Docker Compose
- Dedykowane narzędzia: Pact i Spring Cloud Contract
-
Wdrożenie w projekcie- Strategia pierwszego minimalnego testu kontraktowego
- Weryfikacja zgodności kontraktu po obu stronach integracji
- Strategia pierwszego minimalnego testu kontraktowego
-
Publikowanie kontraktu i wyniku weryfikacji- Wykorzystanie brokera do publikacji i weryfikacji
- Definicja kontraktów ‘In Progress’ i ‘Pending’
- Wykorzystanie brokera do publikacji i weryfikacji
-
Rozbudowane testy kontraktowe- Testy komunikacji asynchronicznej
- Test Fixtures zapewniające utrzymywalność testów kontraktowych
- Zarządzanie stanem i parametrami
- Testy komunikacji asynchronicznej
-
Włączenie testów kontraktowych w proces CI/CD- Automatyczna weryfikacja i publikacja kontraktów
- Raportowanie wdrożeń na środowiska
- Włączenie testów kontraktowych w proces Code Review
- Automatyczna weryfikacja i publikacja kontraktów
-
Can I deploy: Bezpieczeństwo wdrożeń- Can I merge: weryfikacja czy Pull Request nie złamie kontraktu
- Can I deploy: czy na danym środowisku oczekiwany kontrakt jest spełniony
- Can I merge: weryfikacja czy Pull Request nie złamie kontraktu
-
Wzorce i antywzorce w testowaniu kontraktów- Strategia testowania stanowego procesu
- Wybór reprezentatywnych zapytań i odpowiedzi
- Unikanie błędów w build pipeline u innych zespołów
- ‘Nie obiecuj i nie oczekuj nic ponad to co w kontrakcie’
- Strategia testowania stanowego procesu
Pobierz program w formacie PDF
Trenerzy
Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.