14 Prop cupboard patterns for managing input test data

The chapter focuses on practical ways to manage input test data in BDD without cluttering scenarios with incidental details. It frames these techniques as “props” kept in a prop cupboard: reusable test data that supports the scenario while keeping the business-facing text concise and essential. The main idea is that default data should be chosen deliberately by the team, documented centrally, and reused consistently so automation remains readable, maintainable, and easy to update.

It begins with simple defaults, showing how a centralized set of domain defaults prevents hard-coded values from spreading through the codebase. When scenarios need a typical object or object hierarchy, a default instance factory can create a ready-made object that callers may then tweak. As object structures become more complex, an object mother takes over by constructing customized default objects and allowing variations through fluent, builder-like methods. This shifts customization responsibility into shared support code, reducing duplication and making default construction more expressive.

The chapter then broadens the same idea to other forms of test data. Custom parameter types help scenarios speak the domain’s language while hiding conversion logic, and data table accessors separate table parsing from step definitions, especially when columns are optional or schemas evolve. For assertions, table comparison helpers provide atomic checks with rich diff output, keeping verification logic compact and diagnostic. Finally, the validation tester pattern shows how default instances and scenario outlines can describe data validation rules clearly by focusing each scenario on only the changed fields, which makes both specification and automation easier to understand and extend.

• The Domain Default pattern provides a way to define default test data in a shared location to provide consistency across the test suite and avoid the maintenance issues of having hard-coded constants spread throughout the codebase.
• The Default Instance pattern shows how to avoid code duplication when building simple default objects and hierarchies using factory methods.
• Modifying default instances for specific test cases can be done by the test case if the factory method returns a mutable instance.
• When returning a mutable instance is not possible use the Object Mother pattern to create a builder that accepts customization instructions before constructing the instance to be returned.
• Fluent interfaces offer a clear, readable mechanism for chaining together builder customization instructions.
• Although enums can sometimes be used to directly model simple domain terminology, the more powerful technique described in the Terminology Promotion pattern uses custom parameter types to provide a more flexible modeling mechanism.
• Data tables are a concise and clear way to include complicated data in a step. Interacting programmatically with tabular representations is hard to read and maintain, so apply the Data Table Accessor pattern to parse the content of data tables into a data structure created expressly to model that data.
• It is not always essential to describe every available property of a data structure in every step. Ensure that the code parsing a data table, and the data structure that models the data, can handle optional properties and provide appropriate default values.
• Data tables can also be useful to express complicated expectations of a scenario. Comparing the actual and expected outcomes, when expressed as tables, is a powerful way support atomic assertions, but use the Data Table Assertion pattern to ensure complete diagnostics are provided across the full comparison.
• Testing data validation can get exponentially more complicated as the number of interacting attributes increase. Apply the Validation Tester pattern to spread data validation testing across multiple scenarios, each of which targets a specific rule that governs a relationship between a subset of the available attributes.

FAQ