## What is Acceptance Testing?
Acceptance testing verifies that software works from a user perspective. It tests complete user workflows, not internal implementation details.
Think of it as testing the entire journey - can users actually accomplish their goals with your software?
## Who Writes Acceptance Tests?
**Developers write acceptance tests.** Not QA, not business analysts, not end users.
Developers understand the codebase, can write maintainable tests, and own the quality of what they build.
## What Acceptance Tests Look Like
Acceptance tests verify user-facing behavior through the UI or API:
**Web App Example**:
```javascript
test("user can complete checkout", async () => {
await login("user@example.com");
await addToCart("Product 123");
await checkout();
await verifyOrderConfirmation();
});
```
**API Example**:
```javascript
test("user registration flow", async () => {
const response = await registerUser({
email: "new@example.com",
password: "secure123"
});
expect(response.status).toBe(201);
expect(response.body.userId).toBeDefined();
// Verify can login immediately
const loginResponse = await login("new@example.com", "secure123");
expect(loginResponse.status).toBe(200);
});
```
Notice: No internal implementation details. Tests focus on user behavior.
## Acceptance Tests vs Unit Tests
**Unit Tests**: Test business logic and edge cases in isolation. Fast, many of them.
**Acceptance Tests**: Test complete workflows through the real UI/API. Slower, fewer of them.
Both are written and owned by developers. Both are automated and run in CI/CD.
## Common Mistakes
**Testing Implementation Details**: Testing internal functions or class methods instead of user-facing behavior.
**Separate QA Team**: Quality is not a separate team. Developers own quality.
**Manual UAT Phase**: Manual testing catches issues automation missed, but automated acceptance tests should already cover core flows.
**Tools Like Cucumber**: GIVEN-WHEN-THEN syntax adds no value. Write tests in your programming language.
## What About Business Stakeholders?
**Developers write tests based on requirements.** Stakeholders define what "done" means, but developers translate that into automated tests.
Before shipping, stakeholders review working software (not tests) to confirm it meets needs.
## Modern Acceptance Testing
**Automated**: Acceptance tests run automatically on every commit.
**Fast Feedback**: Catch issues in minutes, not days.
**Developer-Owned**: Same team writes features and tests.
**Continuous**: No separate UAT phase. Testing happens continuously.
## Tools for Acceptance Testing
**Web**: Playwright, Cypress - test through real browsers
**Mobile**: Detox, Appium - test on actual devices/simulators
**API**: Supertest, REST Assured - test endpoints directly
All integrated into your CI/CD pipeline, running automatically.
## When Do Users Test?
**After automation passes**: Real users explore and provide feedback on usability, workflows, and business value.
This is exploratory testing, not acceptance testing. Catches things automation cannot - confusing UX, missing features, unclear messaging.
## The Bottom Line
Acceptance testing is automated, developer-owned, and focuses on user-facing behavior.
Skip testing implementation details. Test what users actually do. Automate it. Run it continuously.
Quality is not a separate phase or team. It is built in by developers from day one.
