Acceptance Testing
Functional Acceptance Testing at the Boundary
Exercising a system through its front door as a black box, with attention to where test data comes from and what keeps a scenario true as seeds evolve.
Acceptance tests go through the front door. That much is uncontroversial. The part that decides whether they keep their value is test-data provenance: where arranged data comes from, how expectations derive from it, and what happens to a scenario when the seed underneath it changes.
A test that copies reference data is correct on the day it is written and reads as helpful documentation. It becomes a lie the day the seed changes, and the failure surfaces far from the constants that caused it.
The surrounding discipline
Strategy, structure, naming, and assertions. These carry examples in both languages.
- Testing Strategy
- Test Structure and Organization
- Test Naming Conventions
- Test Assertions
- Test Mediators and Spies
- Service-Boundary Testing
A note on C# coverage
Python has a dedicated chapter for functional acceptance testing. C# does not yet. On the C# side the same ground is covered insideService-Boundary Testing, which includes domain-boundary functional acceptance tests.
The guidance itself is language-independent. Only the worked examples differ.