{
    "slug": "acceptance_testing",
    "term": "Acceptance Testing / BDD (Behat)",
    "category": "testing",
    "difficulty": "intermediate",
    "short": "Testing that the system meets business requirements from a user perspective — written in plain language (Gherkin) and automated with Behat in PHP.",
    "long": "Acceptance testing verifies that a feature behaves correctly from the end user's perspective, not just unit-level correctness. Behaviour-Driven Development (BDD) uses Gherkin syntax (Given/When/Then) to write human-readable scenarios that are both documentation and automated tests. Behat is PHP's primary BDD framework — Gherkin feature files are executed against step definitions written in PHP, often driving a real browser via Mink (Selenium, Playwright). Acceptance tests sit at the top of the Test Pyramid — they are slow, brittle if UI-dependent, but catch integration gaps that unit tests miss. Write them for critical user journeys: checkout flow, user registration, payment processing.",
    "aliases": [
        "acceptance tests",
        "UAT",
        "end-to-end acceptance"
    ],
    "tags": [
        "testing",
        "quality",
        "methodology"
    ],
    "misconception": "Acceptance tests are just end-to-end tests with a different name. Acceptance tests verify that the system meets business requirements from the user's perspective — they can be UI-level or API-level. End-to-end tests describe the technical scope; acceptance tests describe the business intent.",
    "why_it_matters": "Acceptance tests verify that the system meets business requirements from the user's perspective — they are the final safety net before release, testing real workflows end-to-end through the UI or API.",
    "common_mistakes": [
        "Too many acceptance tests — they are slow; use them for critical user journeys, not every feature.",
        "Acceptance tests with no domain language — technical assertions instead of business-readable scenarios.",
        "Not running acceptance tests against a production-like environment — passing on dev, failing on prod.",
        "Flaky acceptance tests that are sometimes ignored — a test suite that is sometimes ignored provides no safety net."
    ],
    "when_to_use": [
        "Validating critical user journeys like checkout, authentication, and payment flows.",
        "Ensuring business requirements are correctly implemented before release.",
        "Creating shared understanding between developers, QA, and non-technical stakeholders."
    ],
    "avoid_when": [
        "Testing low-level logic that can be covered by unit or integration tests.",
        "Verifying UI implementation details like CSS, HTML attributes, or layout.",
        "Running on every small code change where faster test layers provide sufficient coverage."
    ],
    "related": [
        "test_driven_development",
        "integration_testing",
        "smoke_testing",
        "test_pyramid"
    ],
    "prerequisites": [
        "integration_testing",
        "behaviour_driven_development",
        "test_pyramid"
    ],
    "refs": [
        "https://docs.behat.org/",
        "https://mink.behat.org/"
    ],
    "bad_code": "// Acceptance test that's too granular — should be a unit test:\n// Test: verify that the password field has a 'required' attribute\n// This is a unit/integration concern, not an acceptance concern\n// Acceptance test should be: 'User cannot log in without providing a password'\n// — the business requirement, not the HTML implementation detail",
    "good_code": "# Behat feature file — written in Gherkin, readable by stakeholders\nFeature: User login\n  Scenario: Successful login\n    Given I am on \"/login\"\n    When I fill in \"email\" with \"user@example.com\"\n    And I fill in \"password\" with \"secret\"\n    And I press \"Log in\"\n    Then I should see \"Welcome back\"\n    And I should be on \"/dashboard\"\n\n  Scenario: Invalid credentials\n    Given I am on \"/login\"\n    When I fill in \"email\" with \"wrong@example.com\"\n    And I fill in \"password\" with \"wrong\"\n    And I press \"Log in\"\n    Then I should see \"Invalid credentials\"",
    "example_note": "Shows how acceptance tests describe user-visible behavior instead of low-level implementation details.",
    "quick_fix": "Write Behat scenarios in business language (Given/When/Then) for the 5-10 most critical user journeys — not every feature needs an acceptance test",
    "severity": "info",
    "effort": "high",
    "created": "2026-03-15",
    "updated": "2026-03-28",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/acceptance_testing",
        "html_url": "https://codeclaritylab.com/glossary/acceptance_testing",
        "json_url": "https://codeclaritylab.com/glossary/acceptance_testing.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Acceptance Testing / BDD (Behat)](https://codeclaritylab.com/glossary/acceptance_testing) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/acceptance_testing"
            }
        }
    }
}