SpecFlow remains my top choice for automated integration testing. I love writing cute little cukes and putting them together in different ways to create different test scenarios. And one of my favorite cuke tricks is using tables to define an object, which I wrote about some time ago.
The CreateInstance<T> extension method provides an easy way to convert that table data into objects for testing, but I really think there should be a better way to populate child properties of complex objects.
Consider this example:
public class Person { public string FirstName { get; set; } public string LastName { get; set; } public Address Address { get; set; } } public class Address { public string Street { get; set; } public string City { get; set; } public string State { get; set; } public string Zip { get; set; } }
It would be nice if you could write a cuke like this:
Given a person | field | value | | firstName | adam | | lastName | prescott | | address.street | 123 number ln | | address.city | anytown | | address.state | ny | | address.zip | 10000 |
And then convert it to a person like this:
[Given(@"a person")] public void GivenAPerson(Table table) { var person = table.CreateInstance<Person>(); ScenarioContext.Current.Set(person); }
But you can’t. Well, you can, but the address property won’t be populated. I didn’t like that, so I decided to grow my own. It works by identifying the child properties in the table and creating sub-tables, then using reflection to find and set the property on the result object. It works recursively, too, so you could even go n properties deep (i.e., address.state.abbreviation).
At its core, it’s just using CreateInstance<T> so you get all the niceties that go along with that. Note also that it only works with the 2-column, vertical tables with field and value columns. I called my extension method BuildInstance since CreateInstance was already taken. Here it is… Enjoy!
using System; using System.Linq; using System.Reflection; using System.Text.RegularExpressions; using TechTalk.SpecFlow; using TechTalk.SpecFlow.Assist; public static class TableExtensions { public static T BuildInstance<T>(this Table table) { T result = table.CreateInstance<T>(); // find sub-properties by looking for "." var propNames = table.Rows.OfType<TableRow>() .Where(x => x[0].Contains(".")) .Select(x => Regex.Replace(x[0], @"^(.+?)\..+$", "$1")); foreach (var propName in propNames) { // look for matching property in result object var prop = typeof(T).GetProperty( propName, BindingFlags.Public | BindingFlags.Instance | BindingFlags.IgnoreCase); if (prop != null) { // create sub-table with relevant rows (field == propName.something) var subTable = new Table("field", "value"); var re = new Regex(string.Format(@"^{0}\.([^\.]*)$", propName), RegexOptions.IgnoreCase); table.Rows.OfType<TableRow>().Where(x => re.IsMatch(x[0])) .Select(x => new[] { re.Replace(x[0], "$1"), x[1] }) .ToList() .ForEach(x => subTable.AddRow(x)); // make recursive call to create child object var createInstance = typeof(TableExtensions) .GetMethod( "BuildInstance", BindingFlags.Public | BindingFlags.Static, null, CallingConventions.Any, new Type[] { typeof(Table) }, null); createInstance = createInstance.MakeGenericMethod(prop.PropertyType); object propValue = createInstance.Invoke(null, new object[] { subTable }); // assign child object to result prop.SetValue(result, propValue); } } return result; } }
Why not just load the address into the person? That is, a step to load person and another to load address. I don’t normally associate an address as an attribute or characteristic of a person. It feels like your step is doing two things and rigidly welding two separate concepts (a person and an address) into one. That might backfire later if you just need a person or just an address in a later test.
That’s really an excellent way.but I was wondering how to handle an object containing a list of object example list in your person class
Thank you a lot. You solution worked fine for me (just had to remake it for horizontal oriented tables)