Comments on: Encapsulating Test Data and Expectations http://lostechies.com/johnteague/2008/08/13/encapsulating-test-data-and-expectations/ Wed, 08 May 2013 18:43:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: jcteague http://lostechies.com/johnteague/2008/08/13/encapsulating-test-data-and-expectations/#comment-27 jcteague Tue, 09 Sep 2008 13:02:41 +0000 /blogs/johnteague/archive/2008/08/12/encapsulating-test-data-and-expectations.aspx#comment-27 @Aaron Yes, I read that a long time ago. Your approach is definitely one of the more elegant approaches to fluent builders out there. Like I said in the post and my comment to Colin, for complicated objects fluent builder are great. But if you have simple object and you don't want a bunch of one-off static methods, this approach is useful @Aaron
Yes, I read that a long time ago. Your approach is definitely one of the more elegant approaches to fluent builders out there. Like I said in the post and my comment to Colin, for complicated objects fluent builder are great. But if you have simple object and you don’t want a bunch of one-off static methods, this approach is useful

]]> By: Aaron Jensen http://lostechies.com/johnteague/2008/08/13/encapsulating-test-data-and-expectations/#comment-26 Aaron Jensen Tue, 09 Sep 2008 12:48:37 +0000 /blogs/johnteague/archive/2008/08/12/encapsulating-test-data-and-expectations.aspx#comment-26 Have you seen this? http://blog.eleutian.com/2007/09/29/FluentFixtures.aspx Have you seen this?
http://blog.eleutian.com/2007/09/29/FluentFixtures.aspx

]]> By: jcteague http://lostechies.com/johnteague/2008/08/13/encapsulating-test-data-and-expectations/#comment-25 jcteague Wed, 13 Aug 2008 22:39:29 +0000 /blogs/johnteague/archive/2008/08/12/encapsulating-test-data-and-expectations.aspx#comment-25 @Colin Nice Post. One of problems I ran into quickly was the number of factory methods I needed with Object Mother pattern, so I wanted a way to set specific values in one place and keep the number down. The delegate lets me set whatever values I want without an explosion of factory methods and overloads. If I was using a lot of the fields in my object (mapping from DTO's as an example) and I set the values in question after the OM created the object, I would be in the same situation I was trying to avoid. @Colin
Nice Post. One of problems I ran into quickly was the number of factory methods I needed with Object Mother pattern, so I wanted a way to set specific values in one place and keep the number down. The delegate lets me set whatever values I want without an explosion of factory methods and overloads.

If I was using a lot of the fields in my object (mapping from DTO’s as an example) and I set the values in question after the OM created the object, I would be in the same situation I was trying to avoid.

]]> By: Colin Jack http://lostechies.com/johnteague/2008/08/13/encapsulating-test-data-and-expectations/#comment-24 Colin Jack Wed, 13 Aug 2008 10:03:58 +0000 /blogs/johnteague/archive/2008/08/12/encapsulating-test-data-and-expectations.aspx#comment-24 Agree about dislike of approach in "should_sum_all_line_item_prices_times_quantity", I prefer one of the approaches described here (http://xunitpatterns.com/Creation%20Method.html). In particular when calling an OBJECT MOTHER if something isn't clear from the method name and isn't passed in then I don't think your tests should rely on it because if they do then they get fragile and confusing. Haven't tried the solution you describe but did you consider just getting the OM to create an object and then changing any values that are important in the test? So in "should_sum_all_line_item_prices_times_quantity" you'd use OM to create an empty sales order (if that is allowed) and then you'd add the line items in the test (line items presumably being VALUE OBJECTS and thus suiting a builder). Does delegates add something over that approach. Anyway so far my approach has been to use TEST DATA BUILDER for value objects and then OBJECT MOTHER for Entities. However in a few cases I've added a BUILDER style fluent interface on top of the OBJECT MOTHER for an entity, for example this fluent interface gives me an easy way to say "Give me a customer with a relationship to an account manager who works for the company Spondooliks". Gotta finish a blog entry about the approach I've used as I'm interested in knowing why its total rubbish :) Note: I capitilized pattern names to try and make it clear what I mean. Agree about dislike of approach in “should_sum_all_line_item_prices_times_quantity”, I prefer one of the approaches described here (http://xunitpatterns.com/Creation%20Method.html). In particular when calling an OBJECT MOTHER if something isn’t clear from the method name and isn’t passed in then I don’t think your tests should rely on it because if they do then they get fragile and confusing.

Haven’t tried the solution you describe but did you consider just getting the OM to create an object and then changing any values that are important in the test? So in “should_sum_all_line_item_prices_times_quantity” you’d use OM to create an empty sales order (if that is allowed) and then you’d add the line items in the test (line items presumably being VALUE OBJECTS and thus suiting a builder). Does delegates add something over that approach.

Anyway so far my approach has been to use TEST DATA BUILDER for value objects and then OBJECT MOTHER for Entities. However in a few cases I’ve added a BUILDER style fluent interface on top of the OBJECT MOTHER for an entity, for example this fluent interface gives me an easy way to say “Give me a customer with a relationship to an account manager who works for the company Spondooliks”. Gotta finish a blog entry about the approach I’ve used as I’m interested in knowing why its total rubbish :)

Note: I capitilized pattern names to try and make it clear what I mean.

]]>