!**< test
!define releaseManager (|''Name''|Mike|
)
!define stories1 (|''Description''|''Estimated Time''|''Actual Time''|
|Extract calculation rule|3||
)
!define iterations (|''Week''|''Assigned stories''|
|1|${stories1}|
)
!define allStories (|''Description''|''Estimated Time''|
|Extract calculation rule|3|
|Introduce action|1|
)
**!
Nested tables are not going to suit everyone. If they're too complicated for anyone in your team, I suggest you don't use them.

Nested tables allow storytests to show more of the structure of the domain. This is useful for Value Objects that have some structure. It's also useful when a domain object is an Aggregate (in the Domain Driven Design sense). I've worked on real storytests for a complex business domain with 5 levels of nesting that make perfect sense, as they lay our clearly the relationship between the domain objects.

For example, a ''Release'' has a ''Release Manager'', with various details, and is made up of a set of stories and a sequence of ''Iterations''. Each ''Story'' in turn has one or more ''Customers'' and a set of ''Storytests''. A ''Story'' in turn may be assigned to a ''Storytest''. Here's an example ''Release'' that we could use as a part of a storytest:

|''Release''|
|''Name''|First Quarter 2007|
|''Release Manager''|${releaseManager}|
|''Iterations''|${iterations}|
|''Stories''|${allStories}|

Notice that:
 * The property-value pairs of domain objects are laid out side-by-side
 * Collections of values have a header row, followed below by zero or more rows for each of the elements
 * This is similar to the way that a UI may be laid out
Let's look at our first simple example, ^NestedListsAndSets.