Complex.SpecFlow.Assist adds extension methods to the Table object to help create complex objects from a vertical table definition.
It supports collectios, complex properties, dictionaries and even tuples.
You need to specify a vertical table using a flat hierarchical description of the object.
The basics:
Here is an example:
Consider a class defined as:
public class Basic {
public int Id { get; set; }
public string String { get; set; }
public int Integer { get; set; }
public decimal Decimal { get; set; }
public bool Boolean { get; set; }
public DateTime DateTime { get; set; }
public Guid Guid { get; set; }
}
In the .feature file, you could define the table as:
Given I define a table like
| Field | Value |
| Id | 2 |
| String | "Some string." |
| Integer | 42 |
| Decimal | 3.141592 |
| Boolean | True |
| DateTime | "2020-02-20T12:34:56.789" |
| Guid | "1f576fa6-16c9-4905-95f8-e00cad6a8ded" |
The names in the header are ignored.
And in the steps definition you could define the method as:
[Given(@"I define a table like")]
public void GivenIDefineATableLike(Table table) {
var inut = table.CreateComplexInstance<Basic>();
// input will be seeded with the above table.
}
You could also create a argument tranformation like:
[StepArgumentTransformation]
public static Basic AsComplexObject(Table table)
=> table.CreateComplexInstance<Basic>()!;
And instead, define the above method as:
[Given(@"I define a table like")]
public void GivenIDefineATableLike(Basic input) {
// input will be seeded with the above table.
}
Very complex classes
Here are samples of some complex structures supported by the library:
Sample 1 - Nullable values
Any case insensitive combination of null, default, an empty cell, or by simply not adding the property to the list would add a null value to the nullable field.
For empty strings use "".
public class Nullables {
public string? String { get; set; }
public int? Integer { get; set; }
public decimal? Decimal { get; set; }
public bool? Boolean { get; set; }
public DateTime? DateTime { get; set; }
public Guid? Guid { get; set; }
}
In the .feature file, you could define the table as:
Any Collections interfaces (like ICollection<>, IEnumerble<>, etc) or concrete types (like Arrays, Lists<>, etc) are supported.
Even multi-dimentional collections are supported.
public class Colletions {
public ICollection<string>? Lines { get; set; }
public int[]? Numbers { get; set; }
public ICollection<ICollection<ICollection<int>>>? Items { get; set; }
}
In the .feature file, you could define the table as:
The indexes must be defined in a sequence.
That means they must start at 0 and always increment by one.
A table with an invalid index will throw an InvalidDataException.
Sample 3 - Complex properties
Any combination os complex classes or collections are supported including self reference types.
public class Colletions {
public int Id { get; set; }
public Basic? Complex { get; set; }
public ICollection<Nullables>? Children { get; set; }
public Complex? Complex { get; set; }
}
In the .feature file, you could define the table as:
As you can see the conbination of complex properties and collections can produce a wild range of possibilities.
Sample 4 - Dictionaries and Tuples
Dictionaries are defined the same way that complex properties are, but the keys are not limited to the names of the fields/properties in a strong typed property.
Tuples must follow the numeric item name ('Item1', 'Item2', etc). Even named tuples have to folow that definition, although the final object will have the named fields correctly filled.
public class Colletions {
public IDictionary<string, string?> Family { get; set; }
public (int Number, string Street) Address { get; set; }
public ICollection<(int, int)> Points { get; set; }
}
In the .feature file, you could define the table as:
