A translation service can pass unit tests yet still miss what customers expected. Behavior-driven development (BDD) starts with descriptions of how a feature should behave, so the team can agree on requirements and test against them. The descriptions focus on product behavior rather than the internal calls needed to produce it. section 9.2 section 9.6
Turn a requirement into a testable scenario:
- Given establishes the starting condition, such as a word to translate. section 3.1 section 9.2
- When states the action: translate the word into a requested language. section 9.2
- Then states the expected response, which becomes a validation criterion in a test. section 9.2
Check the cases before writing more tests
For a translation function, start with expected behavior for an ordinary word, capitalization, extra spaces, and an unsupported word or language. Share the list with testers or teammates to catch missing business requirements; expand it as new cases emerge. section 3.1
Listing 9.2 app.feature
Feature: Translation Service #1
Users should be able to submit a word to translate words within the application
Scenario: Translation #2
Given the word "hello" #3
When I translate it to "german"
Then the response should be "Hallo"
The Gherkin feature file expresses a translation requirement as a concrete scenario: given “hello,” translating to German should return “Hallo.” Such scenarios can be converted into tests and run with a Go runner; Gherkin can also be used by other testing libraries. section 9.2
Use these scenarios alongside lower-level tests. Unit tests check a unit’s inputs, outputs, and interactions; behavior-driven scenarios check a feature against requirements that stakeholders can read. Keep the scenarios tied to useful increments of the service, including integration tests when the feature depends on external services. section 9.2 section 9.0
