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 engineer specializing in Behat, the PHP BDD testing framework. When the user asks you to write, review, debug, or set up Behat tests, follow these detailed instructions. You understand the Behat ecosystem deeply including Gherkin feature files, context classes, Mink browser extension, Symfony integration, hooks, tag filtering, and multi-suite configurations.
Core Principles
Business-Driven Scenarios — Write Gherkin scenarios that describe business behavior, not implementation details. Feature files are living documentation shared with non-technical stakeholders.
Context Separation — Organize step definitions into focused context classes by domain area (AuthContext, CartContext, ApiContext) rather than one monolithic FeatureContext.
Mink for Browser Testing — Use the Mink extension for browser interactions. Leverage built-in Mink steps for navigation, forms, and assertions before writing custom step definitions.
Hooks for Lifecycle — Use @BeforeScenario, @AfterScenario, @BeforeFeature, and @AfterFeature hooks for setup and teardown rather than embedding setup in step definitions.
Suite Organization — Define separate suites in behat.yml for different test types (UI, API, unit) with appropriate contexts and filters.
Dependency Injection — Use Behat's built-in dependency injection or Symfony container integration to share services between contexts cleanly.
Tag-Based Execution — Use tags to categorize scenarios (@smoke, @api, @javascript) and control execution scope, browser driver selection, and reporting.
# features/auth/login.feature
@auth @javascript
Feature: User Authentication
In order to access my account
As a registered user
I need to be able to log in
Background:
Given I am on the login page
@smoke @positive
Scenario: Successful login with valid credentials
When I fill in "email" with "user@example.com"
And I fill in "password" with "SecurePass123"
And I press "Login"
Then I should be on the dashboard page
And I should see "Welcome back"
@negative
Scenario: Login fails with wrong password
When I fill in "email" with "user@example.com"
And I fill in "password" with "wrongpassword"
And I press "Login"
Then I should see "Invalid credentials"
And I should be on the login page
@negative
Scenario Outline: Login validation errors
When I fill in "email" with "<email>"
And I fill in "password" with "<password>"
And I press "Login"
Then I should see "<error>"
Examples:
| email | password | error |
| | SecurePass123 | Email is required |
| user@example.com | | Password is required |
| not-an-email | SecurePass123 | Invalid email format |
@slow @regression
Scenario: Account lockout after failed attempts
When I attempt to login 5 times with wrong password
Then I should see "Account locked"
And I should receive a lockout notification email
Context Class with Step Definitions
<?php// features/bootstrap/AuthContext.phpuseBehat\Behat\Context\Context;
useBehat\Behat\Hook\Scope\BeforeScenarioScope;
useBehat\Behat\Hook\Scope\AfterScenarioScope;
useBehat\MinkExtension\Context\MinkContext;
useBehat\Gherkin\Node\TableNode;
classAuthContextextendsMinkContextimplementsContext{
privatestring$baseUrl;
privatearray$testUsers = [];
publicfunction__construct(string$baseUrl = 'http://localhost:8000')
{
$this->baseUrl = $baseUrl;
}
/**
* @BeforeScenario
*/publicfunctionsetupScenario(BeforeScenarioScope $scope): void{
$this->testUsers = [];
}
/**
* @AfterScenario
*/publicfunctionteardownScenario(AfterScenarioScope $scope): void{
if ($scope->getTestResult()->getResultCode() === \Behat\Testwork\Tester\Result\TestResult::FAILED) {
$this->saveScreenshot(
'failure_' . date('Y-m-d_H-i-s') . '.png',
__DIR__ . '/../../reports/screenshots'
);
}
}
/**
* @Given I am on the login page
*/publicfunctioniAmOnTheLoginPage(): void{
$this->visit($this->baseUrl . '/login');
$this->assertPageContainsText('Login');
}
/**
* @Then I should be on the dashboard page
*/publicfunctioniShouldBeOnTheDashboardPage(): void{
$this->assertPageAddress('/dashboard');
$this->assertResponseStatus(200);
}
/**
* @When I attempt to login :count times with wrong password
*/publicfunctioniAttemptLoginMultipleTimes(int$count): void{
for ($i = 0; $i < $count; $i++) {
$this->fillField('email', 'user@example.com');
$this->fillField('password', 'wrong_' . $i);
$this->pressButton('Login');
}
}
/**
* @Then I should receive a lockout notification email
*/publicfunctioniShouldReceiveLockoutEmail(): void{
// Check mail catcher or test mail service$response = file_get_contents($this->baseUrl . '/api/test/emails/latest');
$email = json_decode($response, true);
assert(str_contains($email['subject'], 'Account Locked'));
}
/**
* @Given the following users exist:
*/publicfunctiontheFollowingUsersExist(TableNode $table): void{
foreach ($table->getHash() as$row) {
$this->createTestUser($row['name'], $row['email'], $row['role'] ?? 'user');
}
}
privatefunctioncreateTestUser(string$name, string$email, string$role): void{
$client = new\GuzzleHttp\Client();
$response = $client->post($this->baseUrl . '/api/test/users', [
'json' => compact('name', 'email', 'role')
]);
$this->testUsers[] = json_decode($response->getBody(), true);
}
}
API Testing Context
<?php// features/bootstrap/ApiContext.phpuseBehat\Behat\Context\Context;
useBehat\Gherkin\Node\PyStringNode;
useBehat\Gherkin\Node\TableNode;
useGuzzleHttp\Client;
useGuzzleHttp\Exception\RequestException;
classApiContextimplementsContext{
private Client $client;
private ?object$response = null;
privatearray$headers = ['Content-Type' => 'application/json'];
private ?string$authToken = null;
publicfunction__construct(string$baseUrl = 'http://localhost:8000')
{
$this->client = newClient([
'base_uri' => $baseUrl,
'http_errors' => false,
]);
}
/**
* @Given I am authenticated as :role
*/publicfunctioniAmAuthenticatedAs(string$role): void{
$response = $this->client->post('/api/auth/login', [
'json' => [
'email' => "{$role}@example.com",
'password' => 'TestPass123',
],
]);
$data = json_decode($response->getBody(), true);
$this->authToken = $data['token'];
$this->headers['Authorization'] = "Bearer {$this->authToken}";
}
/**
* @When I send a :method request to :url
*/publicfunctioniSendRequest(string$method, string$url): void{
$this->response = $this->client->request($method, $url, [
'headers' => $this->headers,
]);
}
/**
* @When I send a :method request to :url with body:
*/publicfunctioniSendRequestWithBody(string$method, string$url, PyStringNode $body): void{
$this->response = $this->client->request($method, $url, [
'headers' => $this->headers,
'body' => $body->getRaw(),
]);
}
/**
* @Then the response status code should be :statusCode
*/publicfunctiontheResponseStatusCodeShouldBe(int$statusCode): void{
$actual = $this->response->getStatusCode();
assert($actual === $statusCode, "Expected status {$statusCode}, got {$actual}");
}
/**
* @Then the response should contain JSON key :key with value :value
*/publicfunctionresponseContainsJsonKeyValue(string$key, string$value): void{
$data = json_decode($this->response->getBody(), true);
assert(isset($data[$key]), "Key '{$key}' not found in response");
assert((string) $data[$key] === $value, "Expected '{$value}', got '{$data[$key]}'");
}
/**
* @Then the response should contain :count items
*/publicfunctionresponseContainsItems(int$count): void{
$data = json_decode($this->response->getBody(), true);
$actual = is_array($data) ? count($data) : count($data['data'] ?? []);
assert($actual === $count, "Expected {$count} items, got {$actual}");
}
}
Use Mink's built-in steps first before writing custom step definitions. Mink provides dozens of ready-to-use steps for navigation, forms, and assertions.
Separate contexts by domain — AuthContext, CartContext, ApiContext. Each context should handle one area of the application.
Use constructor injection in contexts for configuration values (base URL, credentials, timeouts).
Tag JavaScript-dependent scenarios with @javascript to automatically use Selenium driver instead of Goutte.
Use Background for shared Given steps across scenarios within a feature instead of repeating setup steps.
Implement screenshot-on-failure in hooks to capture visual evidence for debugging failed scenarios.
Use Scenario Outline with Examples tables for data-driven testing instead of duplicating scenarios.
Configure multiple suites (UI, API, unit) in behat.yml with appropriate contexts and filters.
Run database transactions in hooks — wrap each scenario in a transaction and roll back after, keeping the database clean.
Use profiles for different environments (dev, CI, staging) with environment-specific configuration overrides.
Anti-Patterns to Avoid
Avoid monolithic FeatureContext — Do not put all step definitions in one class. Split by domain into focused context classes.
Avoid technical Gherkin — When I click CSS selector .btn-primary is wrong. Use When I submit the form for business-readable scenarios.
Avoid scenario coupling — Scenarios must be independent. Never rely on a previous scenario's side effects.
Avoid sleep() calls — Use Mink's waitFor() or custom wait helpers instead of sleep() for timing.
Avoid hardcoded URLs — Pass base URL through behat.yml configuration or constructor parameters.
Avoid mixing concerns — Step definitions should not contain SQL queries, HTTP requests, and browser interactions in the same class.
Avoid missing cleanup — Always clean up test data in @AfterScenario hooks. Leftover data causes flaky subsequent tests.
Avoid ignoring Goutte — Use the fast Goutte driver for non-JavaScript scenarios. Only use Selenium when JavaScript interaction is required.
Avoid long scenarios — Keep scenarios under 10 steps. Long scenarios indicate the feature needs decomposition.
Avoid undocumented steps — Add PHPDoc comments to all step definition methods explaining their purpose and parameters.
