Claude Code Selenium: Browser-Tests schneller schreiben und reparieren

Selenium ist das meistgenutzte Framework für Browser-Automatisierung weltweit — und gleichzeitig eines der frustrierendsten. Nicht weil das Framework schlecht ist, sondern weil flaky Tests, fragile Locators und unzuverlässige Waits den Alltag bestimmen. Ein Test schlägt fehl, man weiß nicht warum, startet ihn nochmal — und er läuft durch. Das kostet Zeit, Vertrauen und Nerven.

Claude Code Selenium verändert diesen Arbeitsablauf grundlegend: Locators generieren lassen statt manuell suchen, Waits analysieren statt raten, Page Object Model aufsetzen statt von Grund auf schreiben. Dieser Artikel zeigt, wie das konkret funktioniert.

1. Was ist Selenium?

Selenium ist ein Open-Source-Framework für Browser-Automatisierung. Im Kern steuert es einen echten Browser — Chrome, Firefox, Edge, Safari — über das WebDriver-Protokoll: eine standardisierte API, die Befehle wie "klicke auf dieses Element" oder "gib diesen Text in dieses Feld ein" in Browseraktionen übersetzt.

Selenium wird in mehreren Sprachen unterstützt: Python, Java, JavaScript (Node.js), C#, Ruby und Kotlin. Die Konzepte sind sprachübergreifend identisch — nur die Syntax ändert sich. In der Praxis dominieren Python und Java, Python besonders in Daten- und ML-nahen Projekten, Java in Enterprise-Umgebungen.

• Selenium WebDriver — die Kernbibliothek, mit der Tests geschrieben werden
• Selenium Grid — parallele Ausführung auf mehreren Maschinen oder Browsern
• Selenium IDE — Browser-Plugin für Record-and-Replay (für Prototypen, nicht Produktion)

Das Framework ist seit über 15 Jahren aktiv entwickelt und hat eine riesige Community. Es ist kein Ersatz für Playwright oder Cypress, aber in vielen Projekten bereits gesetzt — und genau dort ist Claude Code am wertvollsten: im laufenden Betrieb, nicht beim Neubeginn.

2. WebDriver-Setup: Python und Java

Der häufigste Einstiegspunkt ist Python. Installation:

pip install selenium

Ein minimales Testskript in Python:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get("https://example.com")

heading = driver.find_element(By.TAG_NAME, "h1")
print(heading.text)

driver.quit()

Seit Selenium 4.6 ist Selenium Manager eingebaut: der passende Browser-Treiber (ChromeDriver, GeckoDriver für Firefox, etc.) wird automatisch heruntergeladen und verwaltet. Manuelles Herunterladen und Pfad-Setzen ist nicht mehr nötig. Das war jahrelang eine der häufigsten Fehlerquellen beim Einstieg — fällt jetzt weg.

In Java sieht das Setup so aus:

// pom.xml (Maven)
<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.x.x</version>
</dependency>

// Java-Beispiel
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
WebElement heading = driver.findElement(By.tagName("h1"));
System.out.println(heading.getText());
driver.quit();

3. Locators: Elemente zuverlässig finden

Die häufigste Ursache für fragile Tests ist ein schlechter Locator — ein Selektor, der ein Element heute findet, aber nach dem nächsten Deploy nicht mehr. Selenium bietet mehrere Strategien über By:

• By.ID — schnellste und stabilste Option, wenn IDs vorhanden und eindeutig sind
• By.CSS_SELECTOR — flexibel, lesbar, performant; erste Wahl wenn keine ID vorhanden
• By.XPATH — mächtig, aber schnell unlesbar; für komplexe Traversierungen
• By.NAME, By.CLASS_NAME, By.TAG_NAME — für einfachere Fälle
• By.LINK_TEXT, By.PARTIAL_LINK_TEXT — für Linktext-Suche

# Stabil: ID oder data-testid
element = driver.find_element(By.ID, "submit-btn")
element = driver.find_element(By.CSS_SELECTOR, "[data-testid='submit-btn']")

# Fragil: positionsabhängige XPath-Ausdrücke
element = driver.find_element(By.XPATH, "//div[3]/button[2]")  # VERMEIDEN

# Mehrere Elemente
items = driver.find_elements(By.CSS_SELECTOR, ".product-card")

Die Faustregel: data-testid-Attribute sind die stabilste Option, weil sie explizit für Tests gedacht sind und nicht durch Layout- oder Style-Änderungen brechen. Claude Code kann analysieren, welche Locators in einem bestehenden Test fragil sind, und stabilere Alternativen vorschlagen — dazu mehr in Abschnitt 6.

4. Waits: Das häufigste Problem in Selenium-Tests

Selenium-Tests laufen oft schneller als der Browser rendern kann. Ein Element wird gesucht, bevor es im DOM ist — der Test schlägt mit NoSuchElementException fehl, obwohl das Element kurz danach erscheinen würde. Das ist die Hauptquelle für flaky Tests.

Implicit Wait

Setzt eine globale Wartezeit für alle find_element-Aufrufe:

driver.implicitly_wait(10)  # Sekunden

Simpel, aber problematisch: bei nicht vorhandenen Elementen wartet Selenium immer die volle Zeit. Außerdem interagiert Implicit Wait mit Explicit Wait auf unvorhersehbare Weise — nie beide zusammen verwenden.

Explicit Wait (empfohlen)

WebDriverWait kombiniert mit expected_conditions ist die robuste Lösung:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, timeout=10)

# Warten bis Element sichtbar ist
element = wait.until(
    EC.visibility_of_element_located((By.ID, "result-container"))
)

# Warten bis Element klickbar ist
button = wait.until(
    EC.element_to_be_clickable((By.CSS_SELECTOR, "[data-testid='submit']"))
)

# Warten bis Text erscheint
wait.until(EC.text_to_be_present_in_element((By.ID, "status"), "Erfolgreich"))

5. Aktionen: Klicken, Tippen, Screenshots, Headless

Die grundlegenden Aktionen in Selenium:

# Klicken
element.click()

# Text eingeben
input_field.send_keys("Suchbegriff")
input_field.send_keys(Keys.RETURN)  # Enter drücken

# Formular
input_field.clear()
input_field.send_keys("neuer Wert")

# Screenshot
driver.save_screenshot("screenshot.png")

# Headless-Modus (kein sichtbares Browserfenster)
from selenium.webdriver.chrome.options import Options
options = Options()
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)

Für komplexere Interaktionen wie Hover, Drag-and-Drop oder Tastenkombinationen gibt es ActionChains:

from selenium.webdriver.common.action_chains import ActionChains

actions = ActionChains(driver)

# Hover über Element
actions.move_to_element(menu_item).perform()

# Drag and Drop
actions.drag_and_drop(source, target).perform()

# Mehrere Aktionen verketten
actions.move_to_element(element).click().send_keys("Text").perform()

6. Claude Code Selenium: So funktioniert die Zusammenarbeit

Hier liegt der eigentliche Mehrwert. Claude Code versteht Selenium-Skripte vollständig — nicht nur die Syntax, sondern auch die typischen Problemmuster. Konkrete Einsatzmöglichkeiten:

Test-Skripte generieren

HTML-Struktur oder URL übergeben, Testanforderungen beschreiben — Claude Code generiert ein vollständiges Skript inkl. Waits und Assertions:

claude "Schreib einen Selenium-Python-Test für das Login-Formular auf
/login. Felder: #email, #password, Button: [data-testid='login-btn'].
Nach erfolgreichem Login soll die URL /dashboard enthalten. Nutze
explizite Waits und pytest."

Flaky Waits reparieren

Das ist vielleicht der häufigste Einsatzfall. Einen Test übergeben, der unzuverlässig schlägt:

claude "Dieser Test schlägt manchmal mit NoSuchElementException fehl,
manchmal läuft er durch. Finde die fragilen Waits und ersetze sie durch
zuverlässige WebDriverWait-Konstrukte:" < test_checkout.py

Claude Code analysiert jeden find_element-Aufruf, prüft ob davor gewartet wird, und ersetzt nackte Suchen durch WebDriverWait mit passenden expected_conditions. Das sind die Fixes, für die man sonst Stunden braucht — weil flaky Tests schwer zu reproduzieren sind.

Locator-Strategien erklären und verbessern

claude "Welche Locators in diesem Test sind fragil? Schlage stabilere
Alternativen vor, ohne die Testlogik zu ändern:" < test_product_page.py

Claude Code erkennt typische Antipatterns: positionsabhängige XPath-Ausdrücke (//div[3]/button[2]), Klassen-Selektoren die sich durch CSS-Änderungen verschieben, oder Locators die auf generierte IDs zeigen. Und es schlägt Alternativen vor, die die Teststabilität langfristig erhöhen.

Page Object Model aufsetzen

Das Page Object Model (POM) ist das wichtigste Architekturmuster für wartbare Selenium-Tests. Die Idee: jede Seite der Anwendung wird als Python-Klasse repräsentiert, die alle Locators und Interaktionen kapselt. Tests nutzen diese Klassen statt direkt auf den Driver zuzugreifen.

Claude Code kann aus einem bestehenden Test-Skript automatisch ein POM ableiten:

claude "Extrahiere aus diesem Selenium-Test ein Page Object Model.
Erstelle separate Klassen für LoginPage und DashboardPage.
Tests sollen nur noch die Page-Objekte verwenden, nicht den Driver direkt." < tests/test_login.py

Das Ergebnis ist eine saubere Struktur: Locators stehen genau einmal, in der Page-Klasse. Wenn sich die UI ändert, ändert man den Locator an einer Stelle — nicht in jedem einzelnen Test. Claude Code versteht dieses Muster und setzt es korrekt um, inklusive __init__ mit dem Driver und typischen Hilfsmethoden wie wait_for_page_load().

"Der Test besteht aus 80 Zeilen mit direkten find_element-Aufrufen. Das POM macht daraus drei Klassen mit je 15–20 Zeilen und fünf Tests, die noch zusammen 30 Zeilen haben."

Das ist keine Übertreibung — POM reduziert den Testcode erheblich, aber den Aufwand des Refactorings haben viele Teams vor sich hergeschoben. Claude Code erledigt dieses Refactoring in Minuten.

Zwei verwandte Artikel die auf diesem Thema aufbauen:

• Claude Code Debugging — wie Claude Code Fehlersuche systematisch beschleunigt
• Claude Code für Python-Projekte — Claude Code im Python-Workflow einsetzen