Testowanie aplikacji webowych z Browser Tools

Czego się nauczysz

• Jak działają browser tools i czym różnią się od klasycznego MCP browser server
• Jak odróżnić manualne dodawanie elementów do chatu od autonomicznej pracy agenta w przeglądarce
• Jak bezpiecznie używać shared pages, sesji ephemeral i browser-based test loop

To nie jest tylko “przeglądarka w VS Code”

Browser tools zmieniają agenta z kogoś, kto tylko opisuje UI, w kogoś, kto może wejść na stronę, kliknąć, wpisać dane, zrobić screenshot i sprawdzić rezultat.

To ogromna różnica praktyczna.

Dwie rzeczy, które łatwo pomylić

W ekosystemie VS Code są tu dwa różne mechanizmy:

• Add Element to Chat
• Browser tools for agents

Pierwszy jest manualnym sposobem dodania fragmentu strony jako kontekstu. Drugi daje agentowi autonomiczną możliwość interakcji z przeglądarką.

Jeśli to zmieszasz, łatwo źle zrozumieć poziom kontroli i ryzyko.

Co potrafią browser tools

Guide o browser agent tools wymienia bardzo konkretne capability:

• otwieranie i nawigację po stronach
• czytanie zawartości strony
• robienie screenshotów
• kliknięcia, hover, drag and drop, typing
• obsługę dialogów
• uruchamianie Playwright code

To oznacza, że agent może zamknąć pełną pętlę:

• zbudować UI
• otworzyć UI
• przetestować UI
• wykryć problem
• poprawić problem

Wbudowane browser tools to nie to samo co MCP Playwright

To ważne rozróżnienie architektoniczne.

Wbudowane browser tools działają bez zewnętrznego MCP servera. Jeśli potrzebujesz szybkiej pracy wewnątrz VS Code, to często prostsza ścieżka.

MCP browser server nadal ma sens w innych scenariuszach, ale browser tools pokazują, że część browser workflow jest już natywnie wbudowana w środowisko agenta.

Domyślnie agent pracuje w izolowanej sesji przeglądarki

To bardzo ważny detal z docsów.

Strony otwierane przez agenta działają w prywatnych, ephemeral sesjach. Nie dzielą ciastek ani local storage z Twoimi innymi kartami.

To jest bardzo sensowny kompromis między użytecznością a bezpieczeństwem.

Shared page to tryb uprzywilejowany

Jeśli klikniesz Share with Agent, agent dostaje dostęp do strony otwartej przez Ciebie, razem z Twoim stanem sesji i logowaniem.

To bardzo wygodne do testów na stagingu albo w zalogowanym panelu. Jednocześnie to moment, w którym poziom zaufania musi skoczyć w górę.

Najzdrowsza praktyka jest prosta:

• nie udostępniaj strony agentowi bez realnej potrzeby
• wyłącz share zaraz po zakończeniu zadania
• pamiętaj, że shared page i ephemeral page to dwa różne modele ryzyka

Integrated browser jest tu pełnoprawnym narzędziem pracy

Sam integrated browser też daje sporo:

• otwieranie wielu kart
• dev tools
• debugowanie przez editor-browser w launch.json
• kontrolę nad storage mode
• wybieranie elementów do chatu

To znaczy, że browser workflow nie kończy się na agencie. Możesz płynnie przełączać się między manualnym debugiem a agentową automatyzacją.

Najlepszy use case: zamknięta pętla build-test-fix

Guide z kalkulatorem jest prosty, ale bardzo dobrze pokazuje wzorzec:

1. Agent tworzy aplikację.
2. Otwiera ją w integrated browser.
3. Testuje interakcje.
4. Wykrywa błąd.
5. Poprawia kod.
6. Waliduje poprawkę.

To jest dokładnie ten rodzaj pracy, w którym browser tools dają jakościowy skok.

Browser tools są eksperymentalne i trzeba to respektować

Dokumentacja oznacza je jako experimental. To ważne nie tylko formalnie.

W praktyce oznacza to, że:

• UI może się zmieniać
• capability mogą ewoluować
• nie warto opierać krytycznego procesu zespołu na założeniu pełnej stabilności

To świetna funkcja do produktywnej pracy, ale nadal trzeba zostawić margines ostrożności.

Ćwiczenie praktyczne

Zaprojektuj workflow testu UI dla własnej aplikacji:

• co agent ma zrobić przez browser tools autonomicznie
• które elementy dodasz ręcznie przez Add Element to Chat
• kiedy użyjesz ephemeral page
• kiedy, jeśli w ogóle, udostępnisz shared page

Na końcu określ, jak rozpoznać, że zadanie wymaga jeszcze klasycznego debuggera albo ręcznej inspekcji, a nie kolejnej iteracji przeglądarkowej przez agenta.

Kluczowe wnioski

• Browser tools dają agentowi autonomiczną pracę na stronach bez zewnętrznego MCP.
• Add Element to Chat i browser tools to dwa różne tryby użycia przeglądarki.
• Ephemeral sessions są domyślnie bezpieczniejsze niż shared pages.
• Największa wartość browser tools pojawia się w zamkniętej pętli build-test-fix dla aplikacji webowych.

Co dalej

Kończysz blok zaawansowanych technik. Ostatni moduł to już praktyka profesjonalna: best practices, security & trust, troubleshooting i finalna ściąga ustawień oraz skrótów do codziennej pracy.