17 Dramatis personae patterns for clear naming of concepts
Clear naming is presented as a practical way to make behavior-driven specifications easier to read and discuss. By giving meaningful names to business concepts, data sets, entities, and even user-facing messages, teams can talk about intended behavior without forcing readers to decode raw technical details. The chapter treats these named concepts as personas, with the actual specification data called persona definitions, and emphasizes that the names and their meaning should be captured in a shared glossary so everyone can understand them consistently.
The chapter then shows how small, local personas can live directly inside a feature file. These in-place personas are useful when the data is simple, relevant to only one feature, and important for understanding the scenario itself. The examples demonstrate how a scenario can create named items in a table, store them in scenario context, and refer to them later through custom parameter types. The same idea is extended to message personas, where scenarios refer to a descriptive key instead of exact UI text, allowing tests to remain readable while supporting changing wording and even localization.
For larger or reusable data sets, the chapter moves the persona definition outside the feature file and, when needed, turns it into a template. External personas are appropriate when the data is too large or too detailed to keep inline, and they are especially valuable when domain experts curate both inputs and expected outcomes. Templated personas reduce duplication by letting scenarios specify only the meaningful variations while reusing a common baseline data set. Across all these patterns, the main message is to keep the specification local enough to be understandable, but flexible enough to avoid repetitive, fragile test data.
Storing a named persona in a context object
Extending the custom parameter type to find the order number of a named order
Assert that correct localized message is generated
Setting the context using a sales traffic external persona
Summary
- It is often useful to give descriptive names to business concepts, data structures, or groups of entities. Every time we introduce a descriptive name, we are creating a persona.
- Every persona has some unique aspect, making it useful for illustrating some part of the system’s expected behavior. Those unique aspects are specified in a persona definition.
- Persona definitions range from a very simple naming of a single entity in one scenario all the way up to a complicated template containing a hierarchy of entities, shared among many feature files.
- The In-place Persona pattern describes how simple persona definitions can be created as part of the feature file.
- In-place personas can be created either in a feature file’s Background block (in which case they can be used by any scenario in the feature file) or in the specific Scenario that they are relevant to.
- Almost every system provides some sort of text intended for users, such as validation messages, labels, prompts, and notifications—and that often needs to be localizable. The Message Persona pattern extends the In-place Persona pattern to help us write meaningful scenarios that handle human-readable text, without needing to provide the actual text.
- Some persona definitions are too large to include in a feature file without harming readability. The External Persona pattern describes how a scenario can make use of a persona definition that is stored in an external file or repository.
- External persona definitions can be used by any feature file that needs them.
- Complicated persona definitions are usually created by domain experts to illustrate expected behavior. Therefore, many external persona definitions will express the expected results alongside the definition.
- When multiple scenarios need to use similar persona definitions, the Templated Persona pattern can be useful to minimize the maintenance cost of creating a different persona definition for each scenario.
- The Templated Persona pattern covers situations where a single persona definition is used as a template to be customized for various scenarios. This can be implemented using a templating library but can also be handled by hand-crafted step definitions.
- External persona definitions are part of the system’s specification and so should be kept alongside, and versioned with, the feature files.
FAQ
What is a persona in the context of this chapter?
A persona is a named concept used to represent a meaningful set of data, an entity, or even a complete structure that helps scenarios describe behavior clearly. It can refer to either a user persona or a data persona, and the name should be understandable to business stakeholders.
Why does the chapter use the term “dramatis personae”?
The title borrows the theatrical term dramatis personae, which means the list of important characters in a work. The chapter uses this idea to describe the set of important business concepts that need clear, descriptive names in BDD scenarios.
When should persona definitions be written directly in a feature file?
Use in-place persona definitions when the data set is small, relevant to a single feature file, and useful for readers to see while understanding the scenario. This supports locality of reference and keeps the scenario self-contained.
What is the In-place Persona pattern?
The In-place Persona pattern is a way to define small persona definitions within the feature file itself, either in the scenario or in a Background block. It is best for personas that are simple and needed only within one feature file.
How does the Message Persona pattern improve scenarios?
The Message Persona pattern lets scenarios refer to user-visible messages by a descriptive key instead of hard-coding the exact text. This improves readability, supports message changes, and can help with localization across multiple languages.
What is the purpose of using a custom parameter type for message personas?
A custom parameter type can translate a message key in the scenario into the actual localized message text at runtime. This allows the scenario to stay readable while the automation code resolves the exact message for assertion.
When should an External Persona be used?
Use an External Persona when the persona definition is too large or complex to include in the feature file, or when the same persona needs to be reused across multiple feature files. External sources such as CSV, JSON, or XML are common choices.
Why is it important to include expected results with external persona data when possible?
Including expected results with the input data helps keep all relevant information in one place and makes the persona easier to validate. It also allows domain experts to be accountable for both the inputs and outputs, reducing inconsistency.
What is the Templated Persona pattern?
The Templated Persona pattern uses an external persona definition as a reusable template, then customizes it for a specific scenario by applying variations such as filtering or placeholder substitution. It reduces duplication and maintenance effort when many similar data sets are needed.
How do domain experts contribute to persona definitions in this chapter?
Domain experts can create and validate persona definitions, especially for large or realistic data sets that are difficult for the team to invent or check manually. Their involvement helps ensure the personas reflect real business behavior and accurate expected outcomes.
Effective Behavior-Driven Development ebook for free
