# How to Use Adversarial Testing Patterns to Find UI Bugs in browserbase/skills

> Discover how to find UI bugs using adversarial testing patterns with Browserbase. Execute scripts to expose edge cases, race conditions, and accessibility issues effectively.

- Repository: [browserbase/skills](https://github.com/browserbase/skills)
- Tags: tutorial
- Published: 2026-05-01

---

**Adversarial testing patterns use the Browserbase `browse` command set to execute deterministic, script-driven sequences that expose UI bugs through edge-case inputs, state race conditions, and accessibility violations.**

Adversarial testing patterns provide a lightweight methodology for probing web application robustness without the overhead of traditional testing frameworks. These patterns are implemented in the `browserbase/skills` repository under [`skills/ui-test/references/adversarial-patterns.md`](https://github.com/browserbase/skills/blob/main/skills/ui-test/references/adversarial-patterns.md), utilizing the declarative `browse` API to automate interactions and capture DOM snapshots. By targeting specific component classes—forms, modals, navigation, and error states—with malicious or boundary inputs, you reveal XSS vulnerabilities, layout regressions, and keyboard navigation gaps that functional tests typically miss.

## Understanding the Adversarial Patterns Framework

The adversarial patterns are built on top of the **`browse`** command set defined in [`skills/ui-test/SKILL.md`](https://github.com/browserbase/skills/blob/main/skills/ui-test/SKILL.md). These patterns are not heavy test suites; they are concise Bash-style scripts that leverage the `bb` CLI (provided by [`skills/browserbase-cli/SKILL.md`](https://github.com/browserbase/skills/blob/main/skills/browserbase-cli/SKILL.md)) to drive browser automation.

Each pattern follows a consistent structure:
1. **Capture baseline state** using `browse snapshot`
2. **Execute adversarial action** via `browse click`, `browse fill`, or `browse press`
3. **Validate result** through subsequent snapshots or `browse eval` assertions

Because the patterns rely only on the generic `browse` API, they port across any web application the Browserbase agent can access.

## Core Adversarial Testing Patterns

The reference file [`skills/ui-test/references/adversarial-patterns.md`](https://github.com/browserbase/skills/blob/main/skills/ui-test/references/adversarial-patterns.md) categorizes tests by UI component type. Below are the essential patterns for uncovering robustness issues.

### Form Resilience Testing

Forms are high-risk surfaces for injection attacks and validation gaps. This pattern tests empty submissions, boundary inputs, special characters, and race conditions.

```bash

# Empty submission

browse snapshot                          # BEFORE: note form fields

browse click @submit-ref                 # ACT: submit empty

browse snapshot                          # AFTER: error messages should appear

# Long input (500+ chars)

browse fill "#name" "aaaaaaaa....(500 chars)"
browse snapshot                          # Check layout & truncation

# Special characters (XSS / SQL-like payload)

browse fill "#name" "<script>alert('xss')</script>"
browse fill "#email" "'; DROP TABLE users;--"
browse snapshot                          # Verify input sanitisation

# Rapid submit

browse click @submit-ref
browse click @submit-ref                 # Click twice immediately

browse snapshot                          # Ensure only one submission processed

```

The `@submit-ref` syntax references elements defined in the UI-test skill's reference system, allowing scripts to remain declarative and maintainable.

### Modal Dialog Lifecycle Validation

Modals often trap focus poorly or fail to handle escape key events. This pattern verifies complete open/close lifecycles and side-effect triggering.

```bash
browse snapshot                          # BEFORE: no dialog in tree

# Open

browse click @trigger-ref
browse snapshot                          # AFTER: dialog element should appear

# ASSERT: dialog role exists in tree

# Escape to close

browse press Escape
browse snapshot                          # AFTER: dialog should be gone

# Re-open and cancel

browse click @trigger-ref
browse snapshot
browse click @cancel-ref
browse snapshot

# Re-open and confirm

browse click @trigger-ref
browse snapshot
browse click @confirm-ref
browse snapshot                          # Dialog gone + side-effect occurred

```

### Navigation and Routing Verification

Client-side routers can fail to update URL state or handle history correctly. This pattern captures URL transitions and back-button behavior.

```bash
browse snapshot                          # BEFORE: note current URL and content

browse click @nav-link-ref               # ACT: click a navigation link

browse wait load
browse get url                           # Check URL changed

browse snapshot                          # AFTER: content matches destination

# Back button

browse back
browse get url                           # Should return to original URL

browse snapshot                          # Content matches original page

```

### Error State Robustness

Applications must gracefully handle empty data sets, 404 routes, and invalid submissions without blank screens or cryptic messages.

```bash

# No data page

browse open http://localhost:3000/items
browse snapshot

# Verify empty-state UI or CTA

# Non-existent route

browse open http://localhost:3000/does-not-exist
browse snapshot

# Expect a 404 page, not a blank screen

# Invalid form data

browse fill "#field" "invalid"
browse click @submit-ref
browse snapshot

# Check helpful error message & input preservation

```

### Keyboard Accessibility Audits

Accessibility gaps often hide in tab order and keyboard activation. This pattern programmatically verifies focus management.

```bash
browse open http://localhost:3000/page
browse wait load

# Tab through all interactive elements

browse press Tab
browse eval "JSON.stringify({tag: document.activeElement?.tagName, text: document.activeElement?.textContent?.trim().slice(0,40), role: document.activeElement?.getAttribute('role')})"

# Repeat until activeElement returns to BODY

# Activate via keyboard

browse press Enter
browse snapshot                          # Verify the action occurred

```

## Analyzing Results with DOM Snapshots

The `browse snapshot` command stores a combined DOM and screenshot artifact after each adversarial action. Store these snapshots to diff against baselines or review manually for visual regressions.

For programmatic validation, chain `browse eval` or `browse get` calls to assert expectations:

- **`browse get url`** verifies routing changes
- **`browse eval`** executes JavaScript to check element states, focus positions, or error message visibility

Since the `browse` commands are deterministic, any failure can be reproduced locally by replaying the same script with `bb run <script>`.

## Integrating Patterns into CI/CD Pipelines

Running adversarial patterns in continuous integration provides early detection of regressions that happy-path tests miss. Save each pattern block as a `.sh` script in your repository, then execute via:

```bash
bb run test-scripts/adversarial-form-validation.sh

```

Store the resulting snapshots as CI artifacts to audit UI state changes across builds. Because the patterns execute against any reachable URL, they validate production deployments, staging environments, or local development servers identically.

## Summary

- **Adversarial testing patterns** are lightweight, reusable scripts stored in [`skills/ui-test/references/adversarial-patterns.md`](https://github.com/browserbase/skills/blob/main/skills/ui-test/references/adversarial-patterns.md) that probe UI robustness.
- The **`browse`** command set provides the automation primitives (`snapshot`, `fill`, `click`, `eval`) without requiring heavy test frameworks.
- Patterns cover **form injection**, **modal lifecycles**, **routing verification**, **error states**, and **keyboard accessibility**.
- **DOM snapshots** captured via `browse snapshot` enable visual regression detection and manual review.
- Execution through the **`bb` CLI** integrates seamlessly into CI/CD pipelines for automated regression detection.

## Frequently Asked Questions

### What distinguishes adversarial testing from standard UI testing?

Standard UI testing typically follows happy-path user flows to verify features work correctly. **Adversarial testing** deliberately injects malformed inputs, triggers race conditions, and probes edge cases to expose security vulnerabilities, layout breakage, and unhandled error states that functional specifications rarely cover.

### How do I execute adversarial patterns locally?

Install the Browserbase CLI from [`skills/browserbase-cli/SKILL.md`](https://github.com/browserbase/skills/blob/main/skills/browserbase-cli/SKILL.md), then save any pattern block as a `.sh` file and run `bb run <script>`. The CLI interprets the `browse` commands using your local or cloud-hosted browser agent, capturing snapshots to your local filesystem for inspection.

### Can these patterns detect actual security vulnerabilities like XSS?

Yes. The patterns specifically include XSS payloads (e.g., `<script>alert('xss')</script>`) and SQL-injection-like strings (e.g., `'; DROP TABLE users;--`) in the **Form Resilience** tests. By capturing snapshots after filling these inputs, you verify whether the application properly sanitizes user input or executes malicious code.

### Which UI components benefit most from adversarial testing patterns?

**Forms and inputs** benefit immediately from injection and validation tests. **Modal dialogs** require lifecycle testing to ensure proper focus trapping and dismissal. **Navigation components** need routing verification to catch history API bugs. Finally, **keyboard-accessible interfaces** require tab-order audits to meet accessibility standards and ensure logical focus management.