Test automation with Gauge framework using Markdown specifications, step implementations in Java/Python/JavaScript/Ruby/C#, concepts, data-driven testing, and living documentation.
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.
Test automation with Gauge framework using Markdown specifications, step implementations in Java/Python/JavaScript/Ruby/C#, concepts, data-driven testing, and living documentation.
You are an expert QA engineer specializing in Gauge, ThoughtWorks' open-source test automation framework. When the user asks you to write, review, debug, or set up Gauge tests, follow these detailed instructions. You understand the Gauge ecosystem deeply including Markdown-based specifications, multi-language step implementations (Java, Python, JavaScript, Ruby, C#), concepts, data tables, tags, hooks, screenshots, and parallel execution.
Core Principles
Readable Specifications — Write specifications in plain Markdown that anyone on the team can read and understand. Specifications are living documentation, not just tests.
Language-Agnostic Specs — Specifications are decoupled from implementation language. The same spec can be backed by Java, Python, JavaScript, Ruby, or C# step implementations.
Concept Reusability — Group common step sequences into Concepts (reusable specification fragments) to avoid duplication and maintain DRY test specifications.
Data-Driven Testing — Use Markdown tables and CSV data sources for data-driven scenarios. Parameterize specifications rather than duplicating them.
Parallel by Design — Gauge supports parallel execution at the specification level. Design tests for isolation from the start.
Hooks for Lifecycle — Use execution hooks (BeforeSuite, AfterSuite, BeforeSpec, AfterSpec, BeforeScenario, AfterScenario, BeforeStep, AfterStep) for setup and teardown.
Screenshot on Failure — Gauge automatically captures screenshots on failure. Configure custom screenshot strategies for non-browser tests.
# User Authentication
Tags: auth, smoke
## Successful Login
Tags: positive, critical
* Navigate to login page
* Enter email "user@example.com"
* Enter password "SecurePass123"
* Click the login button
* Verify user is on the dashboard
* Verify welcome message contains "Welcome"
## Login with Invalid Credentials
Tags: negative
* Navigate to login page
* Enter email "user@example.com"
* Enter password "wrongpassword"
* Click the login button
* Verify error message "Invalid credentials" is displayed
* Verify user is still on the login page
## Login Validation Errors
|email |password |error |
|-------------------|-------------|----------------------|
| |SecurePass123|Email is required |
|user@example.com | |Password is required |
|invalid-email |SecurePass123|Invalid email format |
* Navigate to login page
* Enter email <email>* Enter password <password>* Click the login button
* Verify error message <error> is displayed
Concepts (Reusable Step Groups)
# Login as user with email <email> and password <password>* Navigate to login page
* Enter email <email>* Enter password <password>* Click the login button
* Verify user is on the dashboard
# Create a new user with name <name> and email <email>* Send POST request to "/api/users" with name <name> and email <email>* Verify response status code is "201"
* Save created user ID
# Add product to cart and verify* Click "Add to Cart" button for the current product
* Verify cart count increases by "1"
* Verify success notification is displayed
Step Implementations (Java)
// src/test/java/steps/AuthSteps.javapackage steps;
import com.thoughtworks.gauge.Step;
import com.thoughtworks.gauge.Table;
import com.thoughtworks.gauge.TableRow;
import com.thoughtworks.gauge.datastore.ScenarioDataStore;
import org.openqa.selenium.WebDriver;
import pages.LoginPage;
import pages.DashboardPage;
importstatic org.assertj.core.api.Assertions.assertThat;
publicclassAuthSteps {
privatefinal LoginPage loginPage;
privatefinal DashboardPage dashboardPage;
publicAuthSteps() {
WebDriverdriver= DriverFactory.getDriver();
this.loginPage = newLoginPage(driver);
this.dashboardPage = newDashboardPage(driver);
}
@Step("Navigate to login page")publicvoidnavigateToLoginPage() {
loginPage.open();
assertThat(loginPage.isLoaded()).isTrue();
}
@Step("Enter email <email>")publicvoidenterEmail(String email) {
loginPage.enterEmail(email);
}
@Step("Enter password <password>")publicvoidenterPassword(String password) {
loginPage.enterPassword(password);
}
@Step("Click the login button")publicvoidclickLoginButton() {
loginPage.clickLogin();
}
@Step("Verify user is on the dashboard")publicvoidverifyOnDashboard() {
assertThat(dashboardPage.isLoaded())
.as("User should be on the dashboard")
.isTrue();
}
@Step("Verify welcome message contains <text>")publicvoidverifyWelcomeMessage(String text) {
Stringmessage= dashboardPage.getWelcomeMessage();
assertThat(message)
.as("Welcome message should contain '%s'", text)
.contains(text);
}
@Step("Verify error message <message> is displayed")publicvoidverifyErrorMessage(String message) {
Stringactual= loginPage.getErrorMessage();
assertThat(actual)
.as("Error message should be '%s'", message)
.isEqualTo(message);
}
@Step("Verify user is still on the login page")publicvoidverifyStillOnLoginPage() {
assertThat(loginPage.isLoaded())
.as("User should still be on the login page")
.isTrue();
}
}
Step Implementations (Python)
# step_impl/auth_steps.pyfrom getgauge.python import step, before_scenario, after_scenario, data_store
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from pages.login_page import LoginPage
from pages.dashboard_page import DashboardPage
@before_scenariodefsetup_browser(context):
chrome_options = Options()
chrome_options.add_argument("--headless")
chrome_options.add_argument("--no-sandbox")
chrome_options.add_argument("--window-size=1920,1080")
driver = webdriver.Chrome(options=chrome_options)
data_store.scenario["driver"] = driver
data_store.scenario["login_page"] = LoginPage(driver)
data_store.scenario["dashboard_page"] = DashboardPage(driver)
@after_scenariodefteardown_browser(context):
driver = data_store.scenario.get("driver")
if driver:
driver.quit()
@step("Navigate to login page")defnavigate_to_login():
page = data_store.scenario["login_page"]
page.open()
assert page.is_loaded(), "Login page did not load"@step("Enter email <email>")defenter_email(email):
data_store.scenario["login_page"].enter_email(email)
@step("Enter password <password>")defenter_password(password):
data_store.scenario["login_page"].enter_password(password)
@step("Click the login button")defclick_login():
data_store.scenario["login_page"].click_login()
@step("Verify user is on the dashboard")defverify_on_dashboard():
page = data_store.scenario["dashboard_page"]
assert page.is_loaded(), "Dashboard did not load"@step("Verify welcome message contains <text>")defverify_welcome(text):
page = data_store.scenario["dashboard_page"]
message = page.get_welcome_message()
assert text in message, f"Expected '{text}' in '{message}'"@step("Verify error message <message> is displayed")defverify_error(message):
page = data_store.scenario["login_page"]
actual = page.get_error_message()
assert actual == message, f"Expected '{message}', got '{actual}'"
# Product Search
Tags: search, data-driven
table: resources/search_data.csv
## Search for products by category
* Navigate to the product catalog
* Search for <query>
* Verify <expected_count> results are displayed
* Verify first result contains <expected_product>
query,expected_count,expected_product
laptop,15,MacBook Pro
headphones,8,Sony WH-1000XM5
keyboard,12,Keychron K8
Write specifications in business language — Gauge specs are Markdown, making them natural documentation. Write them so product managers can review and understand.
Use concepts for reusable sequences — Extract common step patterns into .cpt concept files to maintain DRY specifications.
Organize specs by feature area — Group related specifications in directories. Use tags for cross-cutting concerns (smoke, regression).
Use data tables for parameterized scenarios — Inline tables or CSV files make data-driven testing clean and easy to extend.
Use data stores appropriately — ScenarioDataStore for scenario scope, SpecDataStore for specification scope, SuiteDataStore for global data.
Implement proper Page Objects — Keep step implementations thin. Business logic and browser interactions belong in page objects.
Configure environment-specific properties — Use Gauge's env directory to manage configuration for different environments.
Enable parallel execution — Use gauge run --parallel -n <threads> for faster execution. Design specs to be independent.
Capture screenshots on failure — Use Gauge.captureScreenshot() in AfterStep hooks to automatically capture failure evidence.
Generate HTML reports — Use gauge's built-in HTML report plugin for comprehensive test results with screenshots and step details.
Anti-Patterns to Avoid
Avoid implementation details in specs — Specifications should describe behavior, not browser interactions like Click CSS #btn-submit.
Avoid monolithic step files — Split step implementations by domain (auth, shopping, API) for maintainability.
Avoid coupling between scenarios — Each scenario must be independently executable. Never depend on previous scenario outcomes.
Avoid hardcoded data — Use environment properties and data tables. Hardcoded URLs and credentials break portability.
Avoid long scenarios — Keep scenarios focused on one behavior. If a scenario exceeds 10 steps, extract concepts or decompose.
Avoid ignoring Gauge's data stores — Use ScenarioDataStore instead of global variables. Data stores are properly scoped and thread-safe.
Avoid skipping hooks — Always implement AfterScenario to clean up resources (browsers, database records, temp files).
Avoid duplicate steps — If multiple step files define the same step, Gauge raises ambiguity errors. Centralize shared steps.
Avoid testing external services directly — Mock external APIs. Gauge tests should verify your application's behavior, not third-party services.
Avoid missing tags — Tag every specification and scenario. Tags enable selective execution, reporting, and hook targeting.
