| Tytuł: | Testy kontraktowe w .NET z Pact.NET |
| Kod: | NET-arch-ctnet |
| Kategoria: | Architektura .NET |
| Forma: | 30% wykłady / 70% 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 praktycznego zastosowania testów kontraktowych i narzędzia Pact Broker do zapewnienia maksymalnej pewności, zredukowania kosztów wdrożeń oraz drogich testów manualnych i end-to-end w środowisku mikroserwisowym.
Szkolenie porusza istotne aspekty, takie jak: kto powinien pisać testy kontraktowe, kto jest za nie odpowiedzialny, jak w praktyce wygląda Consumer-Driven Contract Testing i gdzie w strategii testowania umieścić testy kontraktowe, aby dostarczały maksimum wartości.
Na szkoleniu dowiesz się i przećwiczysz konkretne techniki wprowadzania łamiących zmian w API i schematach eventów
Wyróżniki szkolenia
- Zrozumiesz wzorce i antywzorce pisania testów kontraktowych
- Poznasz narzędzie Pact Broker, dzięki któremu odpowiedź na pytanie „czy mogę wdrożyć kod?" stanie się zautomatyzowanym zapytaniem
- Dowiesz się, gdzie uwzględnić testy kontraktowe w swojej strategii testowania
- Poznasz konkretne strategie wprowadzania łamiących zmian w API
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
- Poziomy testów a model 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
- Rodzaje relacji między producentem a konsumentem (Open Host, Conformist, Customer–Supplier)
- Wzorce komunikatów: komendy, zdarzenia i kwerendy
- Komunikacja synchroniczna i asynchroniczna
- Czym jest architektura mikroserwisów
-
Testy kontraktowe a podejście shift-left
- Miejsce testów kontraktowych w piramidzie testowania
- Szybka pętla zwrotna
- Uzasadnienie i koszt stosowania testów kontraktowych
- Miejsce testów kontraktowych w piramidzie testowania
-
Narzędzia do testów kontraktowych w .NET
- Pact.NET – testy kontraktowe dla REST i komunikatów z kolejek
- Alternatywy i uzupełnienia: JSON Schema, stuby, mocki, Docker Compose
- Pact.NET – testy kontraktowe dla REST i komunikatów z kolejek
-
Wdrożenie testów kontraktowych w projekcie
- Strategia pierwszego minimalnego testu kontraktowego
- Weryfikacja kontraktu po stronie konsumenta i dostawcy
- Strategia pierwszego minimalnego testu kontraktowego
-
Publikowanie kontraktów i wyników weryfikacji
- Pact Broker – publikacja kontraktów i rezultatów testów
- Statusy kontraktów: „In Progress” i „Pending”
- Pact Broker – publikacja kontraktów i rezultatów testów
-
Rozbudowane testy kontraktowe
- Testowanie komunikacji asynchronicznej (kolejki)
- Test Fixtures i utrzymywalność testów
- Provider States i matchery – zarządzanie stanem i parametrami
- Testowanie komunikacji asynchronicznej (kolejki)
-
Włączenie testów kontraktowych do CI/CD
- Automatyczna publikacja i weryfikacja kontraktów w pipeline
- Raportowanie wdrożeń na środowiska
- Testy kontraktowe jako część Code Review
- Automatyczna publikacja i weryfikacja kontraktów w pipeline
-
Bezpieczeństwo wdrożeń – „Can I Deploy”
- „Can I Merge” – weryfikacja PR-ów pod kątem kontraktów
- „Can I Deploy” – zgodność kontraktów w danym środowisku
- „Can I Merge” – weryfikacja PR-ów pod kątem kontraktów
-
Wzorce i antywzorce w testowaniu kontraktów
- Testowanie stanowych procesów
- Dobór reprezentatywnych scenariuszy
- Unikanie błędów w pipeline’ach innych zespołów
- Zasada: „Nie obiecuj i nie oczekuj nic ponad to, co w kontrakcie”
- Testowanie stanowych procesów
Pobierz program w formacie PDF
