Using Value Objects in Fitnesse With Nested Tables
December 3rd, 2006 by James CarrToday I discovered something rather cool while playing with FitLibrary. Not only can you just pass primitive types to fixtures, you can also pass in value objects as well (at least in DoFixture) by using nested tables.
Nested tables work pretty interesting, and I couldn’t really find much documentation on it outside of a scant bit on the fitnesse mailing list and what I was able to figure out by fiddling around. To start things off, I thought I’d show off an example I have while putting together an Email Fixture for checking emails in a mail box. In this particular case, this is a portion that sends an email for the fit test for the fixture. Below is what the table with the nested table looks like:
To do this, you have to assign the nested table to a variable, then simply reference the variable within the table.
!define inner_table (|subject|This is a test|
|type|text/plain|
|body|some content|
)
|Email Accessor|
|connect to|*****|using password|test123|on server|example.com|
|check for|0|messages with subject|This is a test|
|send email|${inner_table}|
|disconnect|
The code for the EmailAccessor is simple… simply extend a DoFixture and have a method called sendEmail which takes an argument (in our case, of type EmailMessage):
public class EmailAccessor extends DoFixture{
...
public void sendEmail(EmailMessage message){
this.box.send(message);
}
Now, how does the inner table map to the domain object it represents? The values in the first column map to setters, with the values in the second or further columns as parameters. Below is the relevant method signatures for EmailMessage:
public class EmailMessage{
...
public void setType(String type){
...
}
public void setSubject(String subject){
...
}
public void setBody(String body){
...
}
}
You can even use nested tables within nested tables to map to domain objets for arguments to other domain objects, although it may look a bit complicated at that point. It worked well on a personal project I did some time ago however as the documentation for a standard I was implementing contained a set of nested tables that outlined the message format. 
