„Jaki mamy coverage?” to słabe pytanie, gdy testy pisze albo recenzuje model
Cztery osobne raporty z jednej ścieżki RealWorld: 0%, 41%, 46% i 87%. Żadna z tych liczb nie jest werdyktem, że testy - albo recenzja testów przez model - są dobre.
Cztery osobne raporty z jednej ścieżki RealWorld: 0%, 41%, 46% i 87%. Żadna z tych liczb nie jest werdyktem, że testy - albo recenzja testów przez model - są dobre.
Zielony e2e nie zawsze znaczy, że UI zrobił to, co myślisz. Część asercji jest prawdziwa już na spinnerze albo na złej zakładce - zanim kliknięcie cokolwiek zmieni.
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ę.


Czytelne 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.


Jak 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.


Grudzień 2024: Copilot Chat jest GA. Agenci i Workspace zostają nagłówkiem. Code review nadal nie jest GA. Piramida zostaje.


Listopad 2024: wąski GPT / Assistants na syntetycznych notatkach QA. Prior art z DevDay 2023. Bez nazw klientów i bez premiery produktu.


Październik 2024: GPT-4o mini składa draft z logów nightly. Quality gate zostaje przy teście, nie przy modelu. Bez o1 jako pinu.


Wrzesień 2024: k6 0.53 (k6/browser stable) mierzy obciążenie. Playwright 1.47 zostaje suite funkcyjną. Load na nightly, nie zamiast E2E.


Sierpień 2024: AxeBuilder 4.9 i toHaveAccessibleName w Playwright 1.46. Nie certyfikat WCAG i nie visual z 2022.


Lipiec 2024: Testcontainers Cloud po przejęciu AtomicJar. Offload kontenerów z laptopa i CI, bez przepisywania suite i bez unified plans z grudnia.


Czerwiec 2024: podsumowanie Copilot Enterprise i boty PR-Agent / CodeRabbit. Autofix jest betą CodeQL, nie GA. Bez Claude 3.5.


Maj 2024: model z vision opisuje PNG. Playwright 1.44 toHaveScreenshot zostaje bramką. GPT-4o ma dwa dni, nie jest rdzeniem.


Kwiecień 2024: Copilot Chat GA przy specu Playwright 1.43. Szkic w sidebarze, zielone w runnerze. Bez Workspace i bez GPT-4o.


Marzec 2024: pytam @workspace o kilka plików testów. Copilot Workspace jest early glimpse, nie preview do użycia. Devin tylko jako nagłówek.


Luty 2024: Testim, Mabl i Healenium są starsze niż hype. Playwright 1.41 nie ma oficjalnego self-healing GA. Healing nie leczy flake z CI.


Styczeń 2024: Auto-GPT jest nagłówkiem od wiosny 2023, Copilot Chat jest wreszcie GA, a suite nadal nie ma autonomicznego właściciela. Merguje człowiek.


Grudzień 2023: ChatGPT, GPT-4 i Copilot Chat na preview. Piramida testów zostaje, AI siedzi w szkicu, nie w ownershipie merge'a. Chat nadal nie jest GA.


Listopad 2023: OWASP Top 10 2021 jako mapa ryzyk, ZAP baseline na CI jako dym, Burp ręcznie przy auth. Podstawy dla QA, a nie pentest i nie AI red-team.


Październik 2023: szkic planu testów, checklisty AC i README z ticketu i z kodu. Custom instructions pomagają, ale publikuje człowiek. Trzy skreślenia.


Wrzesień 2023: czat, Copilot i experimental CT przyspieszają pisanie testów. Piramida i triggery CI zostają. Chat nie jest jeszcze public beta dla wszystkich.


Sierpień 2023: mount komponentu React w Playwright 1.37. Nadal experimental, nie GA i nie zamiennik E2E.


Lipiec 2023: log flake'a do GPT-4 / turbo. Hipotezy do odtworzenia, bez self-healing i bez custom instructions.


Czerwiec 2023: Chat Completions do JSON-a pod fixture. Recenzja schematu, bez GPT-4 API i bez PII.


Maj 2023: Copilot Chat po waitliście. Insiders, Nightly, kontekst pliku. Nie GA i nie public beta.


Kwiecień 2023: jak recenzuję sugestie Copilota w testach C# - asercje, izolacja, zmyślone selektory. Copilot for PRs na waitliście. Bez tutoriala czatu.


15 marca 2023: GPT-4 w ChatGPT Plus do dłuższych spec i przypadków. API gpt-4 na waitliście. W edytorze nadal tylko podpowiedzi linii, bez czatu.


Luty 2023: rola, ograniczenia i format wyjścia w ChatGPT. Plus skraca kolejkę. Bez API i bez GPT-4.


Styczeń 2023: ChatGPT w przeglądarce jako szkicownik przypadków. Recenzja człowieka, bez Plus, bez API i bez GPT-4.


Grudzień 2022: Copilot z preview do GA (ghost text, nie czat). Zaczynam migrację na Playwright. Izolacja z 2021 zostaje. ChatGPT jest z 30 listopada - nagłówek, nie narzędzie roku.


Listopad 2022: porównuję toHaveScreenshot w Playwright 1.27, BackstopJS 6.1, Percy, Applitools i starą ścieżkę Cypress. Bez ChatGPT i bez diffowania LLM.


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.


Wrzesień 2022: które testy na PR, a które w nocy. Prędkość vs pewność po roku kontenerów. Izolacja i równoległość już są na blogu - tu trigger.


Sierpień 2022: NuGet Testcontainers 2.1.0 i Playwright 1.25 w jednym YAML (Azure Pipelines albo GitHub Actions). Docker na hoście, bez pułapki container job z listopada 2021.


Lipiec 2022: consumer-driven contracts po stubach HTTP. PactNet 4.1.0 (Rust, spec v3) vs WireMock. Pact jest z 2013, nowa jest warstwa .NET.


21 czerwca 2022 Copilot jest GA: $10/mies. albo $100/rok, trial 60 dni. Nadal podpowiedzi w edytorze, recenzja przed commitem. Nie czat.


Maj 2022: stawiam pusty projekt Playwright 1.22 (TypeScript, trzy przeglądarki, codegen, Trace Viewer). To nie jest skończona migracja z Cypressa.


Kwiecień 2022: Playwright 1.21 i @playwright/test kontra Cypress 9.5.4. To decyzja o starcie migracji, nie premiera narzędzia i nie pogrzeb Cypressa.


Marzec 2022: GitHub Copilot w preview składa szkielety testów NUnit/xUnit i page objectów. Ghost text, recenzja asercji i lokatorów. Nie czat.


Luty 2022: Copilot nadal jest technical preview (waitlista, za darmo). Ghost text w VS Code, Tab i Esc, recenzja sugestii. Nie czat i nie GA.


Styczeń 2022: organizacja testów C# na .NET 6. xUnit 2.4.1 [Fact] i collection fixtures vs NUnit 3.13.2 FixtureLifeCycle. Izolacja stanu przed równoległością.


Grudzień 2021: rok od docker run do Testcontainers na Azure i równoległego CI. Completions GPT-3 to eksperyment na dane, nie czat. Testcontainers i Polly już na blogu.


Jak w listopadzie 2021 odpalam DotNet.Testcontainers 1.5.0 na agencie Azure Pipelines ubuntu-20.04: Docker na hoście, socket i pułapki container job.


Październik 2021: trzy poziomy równoległości. NUnit vs xUnit, VSTest na agencie, plasterki Azure i matrix GitHub Actions. Izolacja zamiast flaków.


Wrzesień 2021: Bogus z ziarnem, Respawn 4 Checkpoint, Testcontainers i WireMock.Net. Strategie izolacji danych bez dumpów produkcyjnych.


Sierpień 2021: Selenium 3.141 i NUnit 3.13. PageFactory obsolete, obiekty fragmentów UI i WebDriver per test zamiast przepisywania Cypress App Actions.


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.


Eksperyment z GPT-3 przez API Completions (davinci) w czerwcu 2021: few-shot prompt na fixture JSON, waitlista, koszt i niedeterminizm. Nie czat.


Jak w maju 2021 mockuję HTTP WireMockiem 2.28: standalone JAR albo obraz rodolpheche/wiremock, mappings i docker-compose.


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.


Jak w marcu 2021 stawiam Selenium Grid 3 w Dockerze (3.141.59-20210311) i co już da się zobaczyć w obrazach Grid 4 beta-1.


Jak w lutym 2021 składam kilka zależności testowych w docker-compose 1.28: profiles, depends_on, up i sprzątanie wolumenów.


Jak w styczniu 2021 stawiam na żądanie izolowane zależności testowe Dockerem - Engine 20.10, Desktop 3.1, docker run, porty, logi i sprzątanie kontenerów.


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.