Zanim odpalisz testy, ktoś czyta zgłoszenie, diff i ustala, co faktycznie sprawdzić. Ten czas rzadko trafia do raportów, a przy wielu PR-ach robi się z niego realny tygodniowy koszt - często zanim w ogóle zacznie si ę mowa o pokryciu czy narzędziach.
Gdy pipeline częściej budzi wątpliwości niż daje jasny werdykt, „zrób rerun” zastępuje diagnozę. QA traci uwagę na szum zamiast na zmianę.
Kontynuuj czytanieCzytelne wyniki Playwrighta w Azure DevOps: publikacja raportu w formacie JUnit, widoczne niepowodzenia w podsumowaniu potoku oraz układ kroków, który ułatwia diagnozę - w parze z analogicznym wpisem o Cypressie.
Kontynuuj czytanieJak uruchomić testy Playwrighta w Azure DevOps: przygotowanie potoku i środowiska pod przeglądarki, trzymanie adresów aplikacji i API w zmiennych oraz ten sam ogólny przepływ co w artykule o Cypressie, przy prostszej konfiguracji po stronie Playwrighta.
Wykrywanie niechcianych zmian wyglądu dzięki zrzutom ekranu w Playwrightcie: obrazy referencyjne, aktualizacja po świadomych zmianach w UI oraz dobór tolerancji, żeby testy były wiarygodne, a nie serią fałszywych alarmów.
Jedna paczka testów pod Chromium, Firefox i WebKit: wybór silników z konfiguracji i z linii poleceń oraz spojrzenie na to, jak dziś łatwiej myśleć o wielu przeglądarkach niż w czasach, gdy Cypress dopiero rozszerzał wsparcie dla Firefoxa i Edge.
Bardziej odporne testy dzięki stałym punktom zaczepienia w markupie zamiast długich, kruchych łańcuchów CSS. Omawiam konwencję test id z dokumentacji Playwrighta i wiążę ją z dobrze znanym podejściem z dobrych praktyk Cypressa.
AI i uczenie maszynowe w generowaniu przypadków testowych: DefectZero, integracja z automatyzacją i większe pokrycie. Krótki przegląd dla inżynierów QA.
Domyślny adres aplikacji i wspólne przygotowanie przed każdym testem, potem przewidywalne sprawdzanie URL-i. Zmienne środowiskowe oddzielają front od API - odpowiednik wpisu o adresach w Cypressie, ale z konwencjami Playwrighta.
Jak układać kod Playwrighta, gdy scenariuszy przybywa: proste funkcje opisujące kroki użytkownika versus klasyczny page object z klasami - i jak to mapuje na znane z Cypressa rozważania między App Actions a obiektami stron.
Cztery realistyczne scenariusze logowania: udane logowanie, złe hasło, nieistniejący użytkownik i puste pola, z przygotowaniem danych przez backend, żeby testy nie wpadały na siebie. Dobry zestaw obok analogicznego wpisu o Cypressie.
Praktyczny start z Playwrightem przy automatyzacji przeglądarki: instalacja oficjalnego runnera, nawigacja, stabilne wyszukiwanie elementów, praca z formularzami i sprawdzanie oczekiwań. Na tym samym przykładowym projekcie co seria o Cypressie, żeby wygodnie porównać oba narzędzia.
W artykule omówiono proces automatyzacji testów funkcjonalnych aplikacji Blazor z wykorzystaniem biblioteki Microsoft.AspNetCore.Mvc.Testing oraz narzędzia Playwright. Autor przedstawia kroki implementacji, począwszy od konfiguracji klasy uruchamiającej aplikację, aż po napisanie testów sprawdzających poprawność działania strony głównej i sekcji FAQ.
Przedstawiono podejście oparte na DI do testowania integracji w aplikacjach .NET, wykorzystujące WebApplicationFactory do testowania w pamięci. Pokazuje, jak wdrażać i przełączać się między różnymi implementacjami funkcji przy użyciu DI, zwiększając stabilność testów i izolację zależności.
Wykorzystanie biblioteki Polly do implementacji polityki ponawiania prób w testach integracyjnych w projektach .NET w celu uwzględnienia warunków wyścigu i zwiększenia stabilności testów. Autor podaje przykład zastosowania logiki ponawiania prób do metod interakcji z bazą danych i podkreśla znaczenie dokładnego zdefiniowania ram czasowych dla optymalnego wykonania testu.
W poście omówiono wyzwania związane z zarządzaniem dużymi zależnościami, takimi jak bazy danych do testów integracyjnych. Przedstawiono TestContainers, narzędzie służące do zarządzania kontenerami do celów testowych. Autor demonstruje jak skonfigurować i wykorzystać TestContainers z bazą danych MSSQL w projekcie .NET.
Wartość wysyłania wyników testów automatycznych do Slacka po procesie budowania CI, opisując rozwiązanie techniczne wykorzystujące PowerShell, Webhooks i API Slack. Takie podejście podnosi jakość testów automatycznych i zachęca do zespołowej analizy wyników testów w różnych środowiskach CI.
Wyjaśniono, jak skonfigurować raportowanie testów Cypress w potokach Azure DevOps. Opisuje kroki konfiguracji raportowania testów przy użyciu formatu JUnit, zapewniając, że awarie testów nie zakłócą potoku, a także zawiera przegląd wynikowych funkcji raportu z testów w Azure DevOps, podkreślając łatwość integracji i potencjał dodatkowych funkcjonalności w przyszłości posty.
W poście omówiono integrację testów Cypress z usługą Azure DevOps w celu zapewnienia ciągłej integracji. Zawiera przewodnik krok po kroku dotyczący konfigurowania potoku CI w Azure DevOps, wprowadzania niezbędnych dostosowań skryptów, obsługi zmiennych środowiskowych i podkreśla znaczenie testowania w procesie CI. Dodatkowo podkreśla łatwość integracji i znaczenie stosowania testowania do CI dla testerów. Kod można znaleźć w serwisie GitHub w celach informacyjnych.
W tym poście omówiono koncepcję testów regresji wizualnej, podczas których podczas testowania porównuje się oczekiwany wygląd interfejsu ze stanem rzeczywistym, aby wykryć defekty, których nie wyłapią tradycyjne testy regresyjne. Wyjaśnia, jak skonfigurować testy regresji wizualnej przy użyciu frameworka Cypress z bezpłatną wtyczką cypress-image-snapshot i podaje przykłady testowania całego ekranu i poszczególnych elementów pod kątem różnic wizualnych, pokazując jego skuteczność w wykrywaniu nawet niewielkich zmian.
Czytelnik bloga rozwiązał zadanie rekrutacyjne dotyczące Selenium WebDriver i poprosił autora o przegląd kodu, który jest dostępny na GitHubie.
Cypress w swojej najnowszej aktualizacji wprowadził obsługę nowych przeglądarek, Firefox i Microsoft Edge. Pomimo pewnych początkowych problemów z instalacją, autor pomyślnie zaktualizował Cypress i przeprowadził testy na tych przeglądarkach, zauważając, że nowe funkcje są przydatne do celów testowych.
Autor przygotował wideo, w którym prezentuje rozwiązanie zadania rekrutacyjnego dotyczącego automatyzacji testów z użyciem Selenium WebDriver i C#. Wideo trwa ponad 2 godziny i zawiera opis zadania, boilerplate oraz rozwiązanie, stanowiąc cenną okazję do nauki dobrych praktyk w tej dziedzinie.
Autor omawia implementację sztucznej inteligencji w automatyzacji testów Selenium WebDriver, w szczególności z wykorzystaniem wtyczki test-ai-classifier. Podczas instalacji napotykają wyzwania, ostatecznie osiągając sukces. Chociaż rozpoznawanie elementów w oparciu o sztuczną inteligencję jest obiecujące, obecnie ma ograniczoną funkcjonalność, a rozwój projektu kryje w sobie potencjał dla przyszłości testów.
W tym wpisie na blogu autor zastanawia się nad idealnym procesem testowym, jaki chcą osiągnąć w swoich projektach, podkreślając znaczenie szybkiej informacji zwrotnej na temat zmian w kodzie oraz wady testowania ręcznego. Opowiadają się za zrównoważonym podejściem, łączącym zarówno testy automatyczne (testy jednostkowe i akceptacyjne), jak i testy manualne, i podkreślają zalety procesu Continuous Delivery w zakresie szybkiej walidacji kodu i korygowania defektów.
Autor podkreśla znaczenie stosowania w testach automatycznych stabilnych i wysokiej jakości selektorów oraz opowiada się za wykorzystaniem w tym celu atrybutu „data-cy” w Cypress. Pokazują, jak dodawać i wykorzystywać te atrybuty w projekcie React, upraszczając złożoność selektora i zwiększając odporność testów, udostępniając łącza do odpowiednich zmian w kodzie w GitHub.
W tym wpisie autor omawia znaczenie prawidłowego zarządzania adresami URL w testach automatycznych i rozwiązuje ten problem, używając haków Cypress do scentralizowania nawigacji URL i ustawień konfiguracyjnych. Wprowadzają także ulepszenia funkcji potwierdzania adresu URL, aby zapewnić dokładne testowanie.
Autor omawia proces refaktoryzacji testów kodu i porównuje dwa podejścia. App Actions i Page Object Model. Zaczynają od wdrożenia akcji aplikacji, tworzenia niestandardowych poleceń i funkcji, aby testy były czystsze i bardziej zorganizowane. Następnie przechodzą do modelu obiektowego strony, tworząc klasy reprezentujące strony i zarządzając działaniami testowymi za pośrednictwem tych klas. Doszli do wniosku, że oba podejścia mają swoje zalety i wady, a wybór zależy od potrzeb i preferencji projektu.
W tym wpisie na blogu omówiono implementację testów logowania za pomocą Cypress na stronie autora. Obejmuje cztery przypadki testowe, udane logowanie, nieprawidłowe hasło, nieistniejący użytkownik i puste pola. Autor pokazuje, jak przygotować dane testowe i wykorzystać framework Cypress do przeprowadzenia tych testów, jednocześnie odnosząc się do problemów z testowaną aplikacją.
Autor podzielił się swoją techniką tworzenia kompleksowych testów z wykorzystaniem narzędzia Cypress dla aplikacji zbudowanych na ASP.NET Core i React. Zawierają instrukcje krok po kroku dotyczące konfiguracji Cypress, tworzenia podstawowych testów umożliwiających odwiedzanie witryny internetowej, wyszukiwanie elementów, klikanie na nie, wprowadzanie asercji i interakcję z polami wejściowymi, podkreślając moc Cypress w testowaniu aplikacji internetowych.
We wstępie do Cypress autor dzieli się swoją techniką tworzenia kompleksowych testów dla aplikacji internetowej zbudowanej na ASP.NET Core i React. Wyjaśniają proces instalacji, w tym instalację Cypress i pisanie podstawowych testów umożliwiających odwiedzanie stron internetowych, wyszukiwanie elementów, klikanie na nie i wykonywanie asercji. Podają także link do swojego repozytorium w celu uzyskania dalszych informacji i wspominają o zamiarze napisania większej liczby testów w przyszłych postach.
