Test automation with Gauge framework using Markdown specifications, step implementations in Java/Python/JavaScript/Ruby/C#, concepts, data-driven testing, and living documentation.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
Gauge Testing
description
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.
