Remember earlier we said that you can write your Gherkin features in the spoken language of your stakeholders? Here’s how.
Putting a # language: comment on the first line of a feature file tells Cucumber which spoken language that feature is written in. If you omit this header, Cucumber will default to English, as you’ve already seen.
Here’s an example of a feature written in Norwegian:
| # language: no |
| Egenskap: Summering |
| For å unngå at firmaet går konkurs |
| Må regnskapsførere bruke en regnemaskin for å legge sammen tall |
| |
| Scenario: to tall |
| Gitt at jeg har tastet inn 5 |
| Og at jeg har tastet inn 7 |
| Når jeg summerer |
| Så skal resultatet være 12 |
If you’re wondering whether Cucumber knows how to speak your language, you can ask it for the list of all valid languages with this command:
| $ cucumber --i18n help |
When you’re working with a particular language, you can discover the keywords by passing the language code (as listed by the previous command) to the --i18 switch. Here’s Japanese, for example:
| $ cucumber --i18n ja |
A project can have a mix of features that use different spoken languages, yes. However, remember that the setting is for a feature, so all the scenarios in a feature have to use the same spoken language.
One of the greatest benefits of working with a tool like Cucumber is the conversations you have with your stakeholders as you write the scenarios. These can help you find gaps and misunderstandings that otherwise might have emerged only after you’d spent days or even weeks working on the code. So, even if you never run the tests, just writing them can help make you go faster.
3.21.248.162