Persisting with Test Data Builders

[inanc]

We are using help from test data builders to create nearly complex objects
graphs. But when it's time come to persist them we are having difficulties.
Domain:

An Article
A Publisher
An Owner

A publisher contains an article. An article only belong to a publisher.
An owner can have many publishers. A publisher can have one owner.

Test Code:

A   aNew().article().build();
B   aNew().article().persist();
C   aNew().article().with(aNew().publisher("a magazine")).build();
D   aNew().article().with(aNew().publisher("a magazine")).persist();

With A, C, it's OK. But, with B and D, should we persist a publisher and its
belongings too (forex. an owner entity with other belongings to that owner
entity an so on, too)? This persisting graph can get complex, this is just a
simplification.

So, how do you persist your objects when using test data builders with
complex domain modelings with complex associations? In this case, our test
only needs to test whether an article contained by a given publisher. One
thing came into my mind is to use aggregate roots.


[Non-text portions of this message have been removed]

[Cenk Çivici]

Simplest solution is in the persist method of your composite object builder,
call persist methods of associated objects cascadingly. So one persist call
to the complex object should persist all associated objects...
On Tue, Sep 29, 2009 at 7:39 PM, Inanc Gumus <inanc.gumus@...> wrote:

>
>
> We are using help from test data builders to create nearly complex objects
> graphs. But when it's time come to persist them we are having difficulties.
> Domain:
>
> An Article
> A Publisher
> An Owner
>
> A publisher contains an article. An article only belong to a publisher.
> An owner can have many publishers. A publisher can have one owner.
>
> Test Code:
>
> A aNew().article().build();
> B aNew().article().persist();
> C aNew().article().with(aNew().publisher("a magazine")).build();
> D aNew().article().with(aNew().publisher("a magazine")).persist();
>
> With A, C, it's OK. But, with B and D, should we persist a publisher and
> its
> belongings too (forex. an owner entity with other belongings to that owner
> entity an so on, too)? This persisting graph can get complex, this is just
> a
> simplification.
>
> So, how do you persist your objects when using test data builders with
> complex domain modelings with complex associations? In this case, our test
> only needs to test whether an article contained by a given publisher. One
> thing came into my mind is to use aggregate roots.
>
> [Non-text portions of this message have been removed]
>
>  
>

[Non-text portions of this message have been removed]

[Ted Young-5]

Can you tell us more why you need to persist the data in your tests?

;ted

On Tue, Sep 29, 2009 at 9:39 AM, Inanc Gumus <inanc.gumus@...> wrote:

>
>
> We are using help from test data builders to create nearly complex objects
> graphs. But when it's time come to persist them we are having difficulties.
> Domain:
>
> An Article
> A Publisher
> An Owner
>
> A publisher contains an article. An article only belong to a publisher.
> An owner can have many publishers. A publisher can have one owner.
>
> Test Code:
>
> A aNew().article().build();
> B aNew().article().persist();
> C aNew().article().with(aNew().publisher("a magazine")).build();
> D aNew().article().with(aNew().publisher("a magazine")).persist();
>
> With A, C, it's OK. But, with B and D, should we persist a publisher and
> its
> belongings too (forex. an owner entity with other belongings to that owner
> entity an so on, too)? This persisting graph can get complex, this is just
> a
> simplification.
>
> So, how do you persist your objects when using test data builders with
> complex domain modelings with complex associations? In this case, our test
> only needs to test whether an article contained by a given publisher. One
> thing came into my mind is to use aggregate roots.
>
> [Non-text portions of this message have been removed]
>
>  
>

[Non-text portions of this message have been removed]

[Adam Sroka-3]

On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...> wrote:
>
>
>
> Can you tell us more why you need to persist the data in your tests?
>

Great question. Moreover, if you are testing persistence why would you
persist differently than you do in production? If you are testing
something other than persistence, why would you persist at all? (Might
be a good time to try mocking.)

[Cenk Çivici]

Probably he is testing the persistence layer, the DAOs for instance. The
responsibility of such classes are to persist or retrieve data so I usually
write integration tests to test this responsibility and instead of doing
something like
new Customer();
customer.setName("Name")
customer.setAge(20);
session.save(customer)

to make the tests straightforward and easy to understand , using builders is
a good idea such as

new CustomerBuilder().name("Name").age(20).persist();



On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...> wrote:

>
>
> On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>>
> wrote:
> >
> >
> >
> > Can you tell us more why you need to persist the data in your tests?
> >
>
> Great question. Moreover, if you are testing persistence why would you
> persist differently than you do in production? If you are testing
> something other than persistence, why would you persist at all? (Might
> be a good time to try mocking.)
>
>  
>

[Non-text portions of this message have been removed]

[Nat Pryce]

We cover this in the persistence chapter of our book "Growing Object
Software, Guided by Tests" (http://www.growing-object-oriented-software.com
).

Basically, there are two scenarios:

1) saves cascade from the persisted object to related objects.  That makes
persisting a complex object graph as easy as persisting a single object.

2) an object has to refer to objects that are already in the database, so
saving the root object does not cascade the save to related object.  In that
case, you need to make sure that the related entity is already in the
database and is in memory and involved in the current transaction when you
build the object graph it is part of.

--Nat

2009/9/29 Inanc Gumus <inanc.gumus@...>

>
>
> We are using help from test data builders to create nearly complex objects
> graphs. But when it's time come to persist them we are having difficulties.
> Domain:
>
> An Article
> A Publisher
> An Owner
>
> A publisher contains an article. An article only belong to a publisher.
> An owner can have many publishers. A publisher can have one owner.
>
> Test Code:
>
> A aNew().article().build();
> B aNew().article().persist();
> C aNew().article().with(aNew().publisher("a magazine")).build();
> D aNew().article().with(aNew().publisher("a magazine")).persist();
>
> With A, C, it's OK. But, with B and D, should we persist a publisher and
> its
> belongings too (forex. an owner entity with other belongings to that owner
> entity an so on, too)? This persisting graph can get complex, this is just
> a
> simplification.
>
> So, how do you persist your objects when using test data builders with
> complex domain modelings with complex associations? In this case, our test
> only needs to test whether an article contained by a given publisher. One
> thing came into my mind is to use aggregate roots.
>
> [Non-text portions of this message have been removed]
>
>  
>

--
http://www.natpryce.com


[Non-text portions of this message have been removed]

[Donaldson, John (GEO)]

Cenk,

Do you have a brief example of a "builder"? Looking at your example of CustomerBuilder, the only way I can understand it working is if CustomerBuilder.name returns a CustomerBuilder object. Which seems counter-intuitive. I guess CustomerBuilder also has a way of extracting the Customer when it's built?

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Cenk Çivici
Sent: 10 October 2009 10:23
To: testdrivendevelopment@...
Subject: Re: [TDD] Persisting with Test Data Builders

Probably he is testing the persistence layer, the DAOs for instance. The
responsibility of such classes are to persist or retrieve data so I usually
write integration tests to test this responsibility and instead of doing
something like
new Customer();
customer.setName("Name")
customer.setAge(20);
session.save(customer)

to make the tests straightforward and easy to understand , using builders is
a good idea such as

new CustomerBuilder().name("Name").age(20).persist();



On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...> wrote:

>
>
> On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>>
> wrote:
> >
> >
> >
> > Can you tell us more why you need to persist the data in your tests?
> >
>
> Great question. Moreover, if you are testing persistence why would you
> persist differently than you do in production? If you are testing
> something other than persistence, why would you persist at all? (Might
> be a good time to try mocking.)
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Nat Pryce]

See: http://www.c2.com/cgi/wiki?TestDataBuilder

--Nat

2009/10/11 Donaldson, John (GEO) <john.m.donaldson@...>

>
>
> Cenk,
>
> Do you have a brief example of a "builder"? Looking at your example of
> CustomerBuilder, the only way I can understand it working is if
> CustomerBuilder.name returns a CustomerBuilder object. Which seems
> counter-intuitive. I guess CustomerBuilder also has a way of extracting the
> Customer when it's built?
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of Cenk Çivici
> Sent: 10 October 2009 10:23
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Subject: Re: [TDD] Persisting with Test Data Builders
>
> Probably he is testing the persistence layer, the DAOs for instance. The
> responsibility of such classes are to persist or retrieve data so I usually
> write integration tests to test this responsibility and instead of doing
> something like
> new Customer();
> customer.setName("Name")
> customer.setAge(20);
> session.save(customer)
>
> to make the tests straightforward and easy to understand , using builders
> is
> a good idea such as
>
> new CustomerBuilder().name("Name").age(20).persist();
>
> On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
>
> >
> >
> > On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>
> <tedyoung%40gmail.com>>
> > wrote:
> > >
> > >
> > >
> > > Can you tell us more why you need to persist the data in your tests?
> > >
> >
> > Great question. Moreover, if you are testing persistence why would you
> > persist differently than you do in production? If you are testing
> > something other than persistence, why would you persist at all? (Might
> > be a good time to try mocking.)
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>

--
http://www.natpryce.com


[Non-text portions of this message have been removed]

[Cenk Çivici]

Yes builder always return itself "this" except the method toCustomer() or
persist() method which returns the built object.
public class CustomerBuilder {

private String name="DEFAULT NAME";
private int age = 25;

public CustomerBuilder name(String name) {
this.name = name;
return this;
}

public CustomerBuilder age(int age) {
this.age = age;
return this;
}

public Customer toCustomer() {
Customer customer = new Customer();
setValue(customer,"name",name); //sets it using reflection
setValue(customer,"age",age); //sets it using reflection
return customer;
}

public Customer persist() {
Customer customer = toCustomer();
SessionManager.getCurrentSession().persist(customer);
return customer;
}

}


}


On Sun, Oct 11, 2009 at 8:39 AM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> Cenk,
>
> Do you have a brief example of a "builder"? Looking at your example of
> CustomerBuilder, the only way I can understand it working is if
> CustomerBuilder.name returns a CustomerBuilder object. Which seems
> counter-intuitive. I guess CustomerBuilder also has a way of extracting the
> Customer when it's built?
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of Cenk Çivici
> Sent: 10 October 2009 10:23
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Subject: Re: [TDD] Persisting with Test Data Builders
>
> Probably he is testing the persistence layer, the DAOs for instance. The
> responsibility of such classes are to persist or retrieve data so I usually
> write integration tests to test this responsibility and instead of doing
> something like
> new Customer();
> customer.setName("Name")
> customer.setAge(20);
> session.save(customer)
>
> to make the tests straightforward and easy to understand , using builders
> is
> a good idea such as
>
> new CustomerBuilder().name("Name").age(20).persist();
>
> On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
>
> >
> >
> > On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>
> <tedyoung%40gmail.com>>
> > wrote:
> > >
> > >
> > >
> > > Can you tell us more why you need to persist the data in your tests?
> > >
> >
> > Great question. Moreover, if you are testing persistence why would you
> > persist differently than you do in production? If you are testing
> > something other than persistence, why would you persist at all? (Might
> > be a good time to try mocking.)
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>

[Non-text portions of this message have been removed]

[Donaldson, John (GEO)]

Ah! Yes, very clear. I'm struggling with an expanding object mother at the moment, and this will do very nicely thank you.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Nat Pryce
Sent: 11 October 2009 10:50
To: testdrivendevelopment@...
Subject: Re: [TDD] Persisting with Test Data Builders

See: http://www.c2.com/cgi/wiki?TestDataBuilder

--Nat

2009/10/11 Donaldson, John (GEO) <john.m.donaldson@...>

>
>
> Cenk,
>
> Do you have a brief example of a "builder"? Looking at your example of
> CustomerBuilder, the only way I can understand it working is if
> CustomerBuilder.name returns a CustomerBuilder object. Which seems
> counter-intuitive. I guess CustomerBuilder also has a way of extracting the
> Customer when it's built?
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of Cenk Çivici
> Sent: 10 October 2009 10:23
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Subject: Re: [TDD] Persisting with Test Data Builders
>
> Probably he is testing the persistence layer, the DAOs for instance. The
> responsibility of such classes are to persist or retrieve data so I usually
> write integration tests to test this responsibility and instead of doing
> something like
> new Customer();
> customer.setName("Name")
> customer.setAge(20);
> session.save(customer)
>
> to make the tests straightforward and easy to understand , using builders
> is
> a good idea such as
>
> new CustomerBuilder().name("Name").age(20).persist();
>
> On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
>
> >
> >
> > On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>
> <tedyoung%40gmail.com>>
> > wrote:
> > >
> > >
> > >
> > > Can you tell us more why you need to persist the data in your tests?
> > >
> >
> > Great question. Moreover, if you are testing persistence why would you
> > persist differently than you do in production? If you are testing
> > something other than persistence, why would you persist at all? (Might
> > be a good time to try mocking.)
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>

--
http://www.natpryce.com


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Donaldson, John (GEO)]

Cenk, yes - it looks very useful and as I replied to Nat - I need one now.
Thanks.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Cenk Çivici
Sent: 11 October 2009 21:34
To: testdrivendevelopment@...
Subject: Re: [TDD] Persisting with Test Data Builders

Yes builder always return itself "this" except the method toCustomer() or
persist() method which returns the built object.
public class CustomerBuilder {

private String name="DEFAULT NAME";
private int age = 25;

public CustomerBuilder name(String name) {
this.name = name;
return this;
}

public CustomerBuilder age(int age) {
this.age = age;
return this;
}

public Customer toCustomer() {
Customer customer = new Customer();
setValue(customer,"name",name); //sets it using reflection
setValue(customer,"age",age); //sets it using reflection
return customer;
}

public Customer persist() {
Customer customer = toCustomer();
SessionManager.getCurrentSession().persist(customer);
return customer;
}

}


}


On Sun, Oct 11, 2009 at 8:39 AM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> Cenk,
>
> Do you have a brief example of a "builder"? Looking at your example of
> CustomerBuilder, the only way I can understand it working is if
> CustomerBuilder.name returns a CustomerBuilder object. Which seems
> counter-intuitive. I guess CustomerBuilder also has a way of extracting the
> Customer when it's built?
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of Cenk Çivici
> Sent: 10 October 2009 10:23
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Subject: Re: [TDD] Persisting with Test Data Builders
>
> Probably he is testing the persistence layer, the DAOs for instance. The
> responsibility of such classes are to persist or retrieve data so I usually
> write integration tests to test this responsibility and instead of doing
> something like
> new Customer();
> customer.setName("Name")
> customer.setAge(20);
> session.save(customer)
>
> to make the tests straightforward and easy to understand , using builders
> is
> a good idea such as
>
> new CustomerBuilder().name("Name").age(20).persist();
>
> On Sat, Oct 10, 2009 at 3:44 AM, Adam Sroka <adam.sroka@...<adam.sroka%40gmail.com>>
> wrote:
>
> >
> >
> > On Fri, Oct 9, 2009 at 5:37 PM, Ted Young <tedyoung@...<tedyoung%40gmail.com>
> <tedyoung%40gmail.com>>
> > wrote:
> > >
> > >
> > >
> > > Can you tell us more why you need to persist the data in your tests?
> > >
> >
> > Great question. Moreover, if you are testing persistence why would you
> > persist differently than you do in production? If you are testing
> > something other than persistence, why would you persist at all? (Might
> > be a good time to try mocking.)
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links