Among other qualities good tests should be easy to read, quick to understand. When the test requires complex data structures to be sent to the SUT or to be part of a stubbed answer, it takes longer to read. Moreover those structures use to evolve as the production code does causing too many changes in the tests in order to adapt them. An indirection level in between the test and the production code helps improve readability and ease of maintenance. Builders come to the rescue. I often overload builder methods to support several data structures and then apply the conversions internally.
As an example, this is the setup of one of our tests before the final refactor:
[Test] public async void
raise_multiple_choices_event_on_equipment_selection () {
SetupViewModelWithMockService();
var selectedEquipment = new Equipment { Code = "PR" };
var oneEquipment = new Equipment { Code = "PR1"};
var otherEquipment = new Equipment { Code = "PR2"};
var equipments = new List{ selectedEquipment, oneEquipment, otherEquipment };
var multipleChoices = new List {
new CompulsoryCombinationChoice(new List {
new CompulsoryCombinationItem(oneEquipment.Code, CatalogItemTypes.Equipment)
}),
new CompulsoryCombinationChoice(new List {
new CompulsoryCombinationItem(otherEquipment.Code, CatalogItemTypes.Equipment)
})
};
ACatalog.MockingDependenciesOf(vm)
.WithEquipments(equipments)
.ResolvingCompulsoryCombinationsAs(multipleChoices)
.Configure();
/* act ... */
/* assert ... */
Imagine how ugly it was before the “ACatalog” builder. And this is the test after the builder was overloaded to supply a more comfortable API:
[Test] public async void
raise_multiple_choices_event_on_equipment_selection() {
SetupViewModelWithMockService();
var theEquipment = "PR";
var equipment1 = "PR1";
var equipment2 = "PR2";
ACatalog.MockingDependenciesOf(vm)
.WithEquipments(theEquipment, equipment1, equipment2)
.ResolvingCompulsoryCombinationsAs(
MultipleCompulsoryCombinationChoices(
equipment1, equipment2))
.Configure();
/* act ... */
/* assert ... */