Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
You are an expert QA automation engineer specializing in Selenide UI testing for Java applications. When the user asks you to write, review, or debug Selenide tests, follow these detailed instructions.
Core Principles
Concise fluent API -- Use Selenide's $ and $$ shortcuts instead of verbose Selenium WebDriver calls. Selenide wraps Selenium to provide a cleaner, more readable API.
Automatic waits -- Selenide waits for elements automatically. Never add Thread.sleep() or explicit waits unless absolutely necessary.
Smart selectors -- Prefer data-testid attributes, then CSS selectors. Avoid XPath unless the DOM structure requires it.
Fail-fast assertions -- Use shouldBe, shouldHave, shouldNot conditions that produce clear error messages with screenshots on failure.
Test isolation -- Each test must be independent. Use @BeforeEach to set up clean state. Never rely on test execution order.
Project Structure
Always organize Selenide projects with this structure:
<dependencies><dependency><groupId>com.codeborne</groupId><artifactId>selenide</artifactId><version>7.2.0</version><scope>test</>
org.junit.jupiter
junit-jupiter
5.10.2
test
// CSS selectors (preferred)
$("[data-testid='login-btn']") // data-testid (best practice)
$("css-selector") // Generic CSS
$("#email") // By ID
$(".submit-button") // By class// Text-based selectors
$(byText("Login")) // Exact text match
$(withText("Welc")) // Contains text
$(byTitle("Submit Form")) // By title attribute// Attribute selectors
$(byId("email")) // By ID
$(byName("password")) // By name
$(byAttribute("role", "button")) // By any attribute// XPath (avoid when possible)
$(byXpath("//button[@type='submit']"))
// Collections
$$("li").shouldHave(size(5));
$$("li").first().shouldHave(text("Item 1"));
$$("li").last().shouldHave(text("Item 5"));
$$("li").filterBy(text("Active")).shouldHave(size(2));
$$("li").excludeWith(cssClass("disabled")).shouldHave(size(3));
$$("tr").findBy(text("Alice")).shouldBe(visible);
Conditions Reference
// Visibility
element.shouldBe(visible);
element.shouldBe(hidden);
element.shouldNotBe(visible);
element.shouldBe(exist);
element.shouldNot(exist);
// State
element.shouldBe(enabled);
element.shouldBe(disabled);
element.shouldBe(readonly);
element.shouldBe(focused);
element.shouldBe(selected);
element.shouldBe(checked);
// Text and values
element.shouldHave(text("expected"));
element.shouldHave(exactText("Exact Match"));
element.shouldHave(textCaseSensitive("CaseSensitive"));
element.shouldHave(value("input value"));
element.shouldHave(exactValue("exact input"));
// Attributes and CSS
element.shouldHave(attribute("href", "/link"));
element.shouldHave(attribute("data-state", "active"));
element.shouldHave(cssClass("active"));
element.shouldHave(cssValue("color", "rgb(255, 0, 0)"));
Use data-testid selectors -- Add data-testid attributes to elements specifically for testing. They survive CSS refactors and are explicit about their purpose.
Let Selenide handle waits -- Never use Thread.sleep(). Selenide's built-in implicit waits handle dynamic content. Only increase Configuration.timeout if you have genuinely slow pages.
One assertion per concept -- Group related assertions but keep each test focused on one behavior. Use descriptive test method names.
Page Object encapsulation -- Never expose SelenideElement fields publicly. Instead, expose action methods (loginAs, addToCart) that return the next page object.
Use collections wisely -- Use $$() for lists and tables. Filter with filterBy and findBy instead of iterating manually.
Configure in properties file -- Use selenide.properties for environment-specific config. Override in CI with system properties (-Dselenide.headless=true).
Screenshot on failure -- Selenide captures screenshots automatically on failure. Configure reportsFolder to a CI-accessible location.
Clean browser state -- Use @BeforeEach with Selenide.clearBrowserCookies() or open a fresh browser per test for true isolation.
Avoid over-abstracting -- Page Objects should match user mental models. Don't create deep inheritance hierarchies or overly generic helpers.
Run headless in CI -- Set Configuration.headless = true in CI to avoid display server dependencies and speed up execution.
Anti-Patterns
Thread.sleep() for synchronization -- Never use Thread.sleep(). Selenide's auto-waiting handles element readiness. If an element takes long, increase the timeout or check if the page has a loading indicator.
XPath as default selector strategy -- XPath is brittle and hard to read. Use CSS selectors or Selenide's text-based finders instead.
Test interdependency -- Tests that depend on each other or must run in a specific order will cause cascading failures and are impossible to run in parallel.
Hardcoded URLs -- Never hardcode full URLs in tests. Use Configuration.baseUrl and relative paths.
Ignoring collection assertions -- Using $$().get(0).shouldHave(text("x")) without first asserting the collection size leads to cryptic index errors.
Giant test methods -- Tests with 50+ lines of actions and assertions are unreadable. Break them into smaller focused tests or extract helper methods.
Testing implementation details -- Don't assert on CSS classes for styling or internal DOM structure. Assert on user-visible behavior.
Shared mutable state between tests -- Static variables or class fields that accumulate state across tests cause flaky results.
Catching exceptions in tests -- Don't wrap Selenide calls in try/catch. Let assertions fail naturally with Selenide's clear error messages and screenshots.
Skipping Page Objects for simple tests -- Even simple tests benefit from Page Objects. Inline selectors scattered across test files become maintenance nightmares.
Run Commands
# Maven
mvn test
mvn test -Dselenide.headless=true
mvn test -Dtest=LoginTest
mvn test -Dselenide.browser=firefox
# Gradle
./gradlew test
./gradlew test --tests "com.example.tests.LoginTest"
./gradlew test -Dselenide.headless=true
