Is this what you're looking for?
https://github.com/techtalk/SpecFlow/wiki/SpecFlow-Assist-Helpers
When it comes to flattening sub-objects, I've had more success not
flattening them in the results and just making another step
definition.
For example, if I have an Order object with Items, I would have a Then
clause like this:
Then an order should exist with the following information:
| OrderID | Total |
| 1234 | 23.45 |
| 7890 | 50.00 |
And the order of id '1234' should have the following items
| Sku | Quantity | Price |
| 1 | 1 | 23.45 |
And the order of id '7890' should have the following items
| Sku | Quantity | Price |
| 2 | 2 | 25.00 |
And running the comparisons for these things are one-line method calls
with SpecFlow, with no special data manipulation necessary.
I think Gherkin works best when you use it to describe your system as
clearly and as accurately as possible. If you have an object with
child objects, then that's what you have: An object with child
objects. If you just stick with that, with steps that identify one
thing (or one special aspect of a thing, like sub-objects), you'll
find that your steps are very reusable. When I've done special
manipulation, my steps have quickly become brittle. Or worse, I've
had to make "special" ones to handle different situations.
And just to further emphasize from my own experience: Sticky tables
are hell. They're hard to maneuver in the step definition. They
trick you into thinking you can change them when you can't. They are
the worst technical debts in that you don't even know you're in debt
until you're already over your head. Beware.
Darren Cauthon