> Generates production-grade Reqnroll BDD automation scripts for web (Selenium 3/4) and mobile (Appium 2) testing in C#. Supports parallel NUnit execution locally and on TestMu AI cloud. Use when the user asks to write BDD tests, automate with Reqnroll, create .feature files, write Gherkin scenarios, write step definitions, migrate from ".feature file", "step definition", "SpecFlow migration", "Selenium C#", "Appium C#", "TestMu", "LambdaTest", "NUnit BDD", "reqnroll.actions.json".
npx skills add https://github.com/LambdaTest/agent-skills --skill reqnroll-skill
This skill guides QA engineers and test architects in writing production-grade Reqnroll
BDD tests for web and mobile automation in C#. It covers three execution paths — Selenium 4
with manual driver management, Selenium 3 via the Reqnroll.Actions plugin, and Appium 2
for Android mobile — all targeting TestMu AI (LambdaTest) cloud infrastructure.
Reqnroll is the actively maintained open-source successor to SpecFlow. Existing SpecFlow
projects can migrate by swapping the NuGet package and namespace — no step definition
rewrites required.
Framework Selection: Distinguishes between Selenium 4 (manual DriverFactory),
Selenium 3 (Reqnroll.SpecFlowCompatibility.Actions.LambdaTest plugin with
IBrowserInteractions), and Appium 2 (Appium.WebDriver, AndroidDriver).
Cloud vs Local: Reads LT_USERNAME and LT_ACCESS_KEY environment variables;
routes to hub.lambdatest.com (web) or mobile-hub.lambdatest.com (mobile).
Reports pass/fail to LambdaTest via lambda-status JavaScript executor calls in
[AfterScenario].
Parallelism: Uses [assembly: Parallelizable(ParallelScope.Fixtures)] with
[assembly: LevelOfParallelism(N)] (NUnit). State is shared between step definition
classes via ScenarioContext (injected by Reqnroll's DI container), not static fields.
Each .feature file maps to one test class. Scenarios are tagged (@tagName) for
selective filtering with dotnet test --filter "Category=tagName". Background steps
run before every scenario in the file; Scenario Outlines drive data-driven testing via
Examples tables.
Classes are decorated with [Binding]. Constructor injection (via Reqnroll's built-in
DI) receives ScenarioContext or shared context objects. One [Binding] class per
concern keeps files small. Regex-based step patterns use (.*) or typed captures
((\d+)) — no attribute-level type converters needed for primitives.
[BeforeScenario] initialises the driver (stored in ScenarioContext["driver"]) and
navigates to the base URL. [AfterScenario] reads _scenarioContext.TestError (web) or
TestContext.CurrentContext.Result.Outcome.Status (mobile) to emit
lambda-status=passed/failed before driver.Quit().
Drivers are stored as _scenarioContext["driver"] = driver and retrieved with
scenarioContext["driver"] as IWebDriver. This is required for parallel execution —
static driver fields cause race conditions.
WebDriverWait with Until(d => d.FindElement(locator)) replaces ImplicitWait
for dynamic content. A WaitAndFind(By) helper method encapsulates the 10-second
default; a WaitAndClick(By, int timeout) variant handles clickability.
var ltOptions = new Dictionary<string, object>
{
{ "build", "Build Name" },
{ "project", "Project Name" },
{ "w3c", true },
{ "selenium_version", "4.38.0" },
{ "sessionName", scenarioName },
{ "platformName", "Windows 11" }
};
var options = new ChromeOptions();
options.BrowserVersion = "latest";
options.AddAdditionalOption("LT:Options", ltOptions);
var driver = new RemoteWebDriver(
new Uri($"https://{userName}:{accessKey}@hub.lambdatest.com/wd/hub"), options);
var ltOptions = new Dictionary<string, object>
{
{ "build", "Build Name" },
{ "project", "Project Name" },
{ "w3c", true },
{ "app", "proverbial-android" }, // lt:// URI or pre-uploaded alias
{ "platformName", "android" },
{ "deviceName", "Galaxy.*" },
{ "platformVersion", "14" },
{ "isRealMobile", true },
{ "autoAcceptAlerts", true },
{ "autoGrantPermissions", true },
{ "sessionName", scenarioName }
};
var appiumOptions = new AppiumOptions();
appiumOptions.AddAdditionalAppiumOption("LT:Options", ltOptions);
var driver = new AndroidDriver(
new Uri($"https://{userName}:{accessKey}@mobile-hub.lambdatest.com/wd/hub"),
appiumOptions);
// Web (AfterScenario)
if (_scenarioContext.TestError == null)
((IJavaScriptExecutor)driver).ExecuteScript("lambda-status=passed");
else
((IJavaScriptExecutor)driver).ExecuteScript("lambda-status=failed");
// Mobile (AfterScenario)
bool passed = TestContext.CurrentContext.Result.Outcome.Status == TestStatus.Passed;
((IJavaScriptExecutor)driver).ExecuteScript("lambda-status=" + (passed ? "passed" : "failed"));
ScenarioContext used for driver sharing — never static fields in parallel runs[assembly: Parallelizable(ParallelScope.Fixtures)] declared once in any .cs fileLT_USERNAME and LT_ACCESS_KEY read from environment — never hardcodedlambda-status=passed/failed emitted in every [AfterScenario] for cloud runsWebDriverWait used throughout — no unconditional Thread.Sleep except transient Appium delaysMobileBy.Id (resource-id) or MobileBy.AccessibilityId before XPathdriver.Quit() always called in [AfterScenario] to free cloud device slotsdotnet test --logger "console;verbosity=detailed" surfaces per-scenario pass/failThe reference/ directory contains detailed playbook sections:
| File | Contents |
|------|----------|
| playbook.md | Full implementation guide: project setup, all three driver modes, parallel execution, CI/CD, debugging table, best practices checklist |
| cloud-integration.md | LambdaTest capability reference, LT:Options fields, tunnel setup, build/session naming, test observability |
| selenium-4-patterns.md | Selenium 4 patterns: DriverFactory, multi-browser, ChromeOptions/FirefoxOptions/EdgeOptions, screenshot on failure |
| selenium-3-patterns.md | Selenium 3 patterns: Reqnroll.SpecFlowCompatibility.Actions.LambdaTest, IBrowserInteractions, reqnroll.actions.json config |
| appium-patterns.md | Appium 2 patterns: AndroidDriver, AppiumOptions, gesture helpers, MobileBy locators, app lifecycle |
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Run Playwright tests at scale with cloud-hosted browsers and integrated Azure portal reporting.
Browser debugging, performance profiling, and automation via Chrome DevTools MCP. Use when user says "debug this page", "take a screenshot", "check network requests", "profile performance", "inspect console errors", or "analyze page load". Do NOT use for full E2E test suites (use playwright-skill) or non-browser debugging.
QA-test a website or web app and return a 1-5 quality score (5 = flawless, 1 = broken) with evidence. Use when the user wants to test, QA, evaluate, score, or "check how good" a site, page, flow, or app — including a local dev server (e.g. "qa test localhost:5173", "does the checkout work?", "rate this landing page"). Drives a real Browser Use cloud browser, tunneling localhost automatically.
Set up component testing with Playwright using a story gallery — scaffold stories and a gallery dev page driven by the built-in mount fixture, no dedicated component-testing runtime. Use when asked to test React or Vue components in isolation with Playwright, or to migrate off @playwright/experimental-ct-react / -vue.
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.
Always use browser-harness for any web interaction: automation, scraping, testing, or site/app work.
Run a browser-based UI review of the WordPress.com Help Center across multiple surfaces, looking for visual and behavioral issues. Use when asked to test the Help Center UI.
Take lambdatest/reqnroll-skill from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.