Is it possible to get the setter getter relationship to work using a mock object?

[Kent Larsson-3]

Hi,

I have a class which I create a mock object of (using class
imposterizer) in our tests, let's call the class SomeEntity. Then I
have another class which I'm testing, it adds an instance of
SomeEntity to a collection, while at the same time giving the instance
a unique identity using the setId(int id) method of SomeEntity. On the
calls after setId I would like to return the value which our
SomeEntity instance was given. Is it possible and how should I go
about doing it?

Best regards,
Kent Larsson

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

1) Entity? Hmmm. Is this really just a data object? Does it have any  
interesting behaviour involving collaborators? If it is just a data  
object, maybe it would be better to use the real thing?

2) What are the uses of this id visible in the tests, could their  
constraints be loosened so that you don't care what its value is?

3) Why is the id not a predictable value in a unit test?

4) If you really have to, you could create a custom action to hold on  
to the given id, but this is probably a bad idea.

S.

On 2 Jun 2008, at 10:07, Kent Larsson wrote:

> Hi,
>
> I have a class which I create a mock object of (using class
> imposterizer) in our tests, let's call the class SomeEntity. Then I
> have another class which I'm testing, it adds an instance of
> SomeEntity to a collection, while at the same time giving the instance
> a unique identity using the setId(int id) method of SomeEntity. On the
> calls after setId I would like to return the value which our
> SomeEntity instance was given. Is it possible and how should I go
> about doing it?
>
> Best regards,
> Kent Larsson
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kent Larsson-3]

> 1) Entity? Hmmm. Is this really just a data object? Does it have any
> interesting behaviour involving collaborators? If it is just a data object,
> maybe it would be better to use the real thing?
>
> 2) What are the uses of this id visible in the tests, could their
> constraints be loosened so that you don't care what its value is?
>
> 3) Why is the id not a predictable value in a unit test?
>
> 4) If you really have to, you could create a custom action to hold on to the
> given id, but this is probably a bad idea.

Thank you for your answer! I really need some help as I'm a novice
mocker and a beginner unit tester. :-)

The short answer:

The id instance variable is used for checknig if two entity instances
are equal. The id's are given from a simulated integration layer,
which gives the id's in sequential order. But it feels a bit dirty to
write the test to depend on the simulated integration layers way of
giving out ids.

The all too long answer: (Sorry, I didn't know how to compress it more
without loosing relevant information)

It's more or  less a data carrier (it's an JPA entity and we have
chosen to have as much logic as possible in the manager EJB classes).
We have a manager class which is responsible for a tree structure of
Library enteties, where each Library may hold n number of UserGroup's.

At the moment the business logic to update the Library tree is
complete. This means adding/updating/removing Library instances and
the UserGroup's they contain.

We want to check that this logic functions according to our business
rules. That means that the manager class does what we expect it to do.
To not make our tests too brittle mocking Library and UserGroup seemed
like a good idea. These are concrete classes but ClassImposteriser
made this less of a problem.

Ideally mocking these two concrete classes would be nice. As the tests
would be less brittle if only the methods needed for the manager test
could be simulated and checked.

However I would like the equals method to work by comparing the id
instance variable to the other instance. Apart from that there really
isn't any logic in the data carrier objects.

As the data carrier objects will change later on and contain more
methods and a constructor taking more parameters the mocking seemed
nice.

Maybe I should be using the real classes for the UserGroup's? I do
this for the Library instances already. When to mock and when not to
mock? That's the question. :-/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

On 2 Jun 2008, at 11:13, Kent Larsson wrote:
> The short answer:
>
> The id instance variable is used for checknig if two entity instances
> are equal. The id's are given from a simulated integration layer,
> which gives the id's in sequential order. But it feels a bit dirty to
> write the test to depend on the simulated integration layers way of
> giving out ids.

if you have a simulation, I would have thought it would be easy to  
seed the ID generation.

> It's more or  less a data carrier (it's an JPA entity and we have
> chosen to have as much logic as possible in the manager EJB classes).
> We have a manager class which is responsible for a tree structure of
> Library enteties, where each Library may hold n number of UserGroup's.
>
> At the moment the business logic to update the Library tree is
> complete. This means adding/updating/removing Library instances and
> the UserGroup's they contain.
>
> We want to check that this logic functions according to our business
> rules. That means that the manager class does what we expect it to do.
> To not make our tests too brittle mocking Library and UserGroup seemed
> like a good idea. These are concrete classes but ClassImposteriser
> made this less of a problem.

Personally, I view class mocking as a problem, but that's just me :)

> Ideally mocking these two concrete classes would be nice. As the tests
> would be less brittle if only the methods needed for the manager test
> could be simulated and checked.

if you're only checking the id field in a data object, then it  
shouldn't be a big deal to use the real class.

> However I would like the equals method to work by comparing the id
> instance variable to the other instance. Apart from that there really
> isn't any logic in the data carrier objects.

you need to be a little bit careful about what equals() means -- has  
the same values or is the same object? If you really want to check the  
ID, you might even consider adding a more precisely named method. You  
can use Hamcrest (included with junit4) to write helpful matchers in  
the tests.

> As the data carrier objects will change later on and contain more
> methods and a constructor taking more parameters the mocking seemed
> nice.
>
> Maybe I should be using the real classes for the UserGroup's? I do
> this for the Library instances already. When to mock and when not to
> mock? That's the question. :-/


In this case, it sounds like the Library stuff is one data structure,  
so it might be best just to use the real thing.

We tend to use mocking when call to the neighbouring implies an  
"action", a change to the world outside the target object--but not  
just updating a data structure.

S

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

On 02/06/2008, Kent Larsson <kent.larsson@...> wrote:
> However I would like the equals method to work by comparing the id
> instance variable to the other instance. Apart from that there really
> isn't any logic in the data carrier objects.

In JPA you REALLY do not want to do this.

The JPA implementation maps  one or more rows in the database to an
object in memory.  Within a transaction, it ensures that a primary key
only ever maps to a single object.  Every time you do a query that
returns a row with that primary key or JPA maps a foreign key
relationship to the primary key, you end up with the same object. This
e ensures that the changes to the object are consistent with what gets
flushed back to the database at the end of the transaction.

Between two transactions, you cannot make the same assumption.  A
primary key in one transaction refers to a different temporary state
than THE SAME primary key in a different transaction.

If you override equals to compare primary keys instead of object
references, you are violating the assumptions of the object relational
mapper. Wierd things happen when you share collections between
transactions.  Objects from one transaction can silently leak into
another transaction or objects can appear to suddenly change state
without warning.

If you're not sharing collections between transactions, then there's
no need to override equals because the JPA implementation just does
the right thing.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nat Pryce]

On 02/06/2008, Kent Larsson <kent.larsson@...> wrote:
> It's more or  less a data carrier (it's an JPA entity and we have
> chosen to have as much logic as possible in the manager EJB classes).

That's a smell.

Certainly, if the persistent entities have no behaviour then you
should not be mocking them.

If all the logic is in the EJB and it manipulates dumb things that it
gets out of the database, then you're using a procedural design.
That's not a bad thing per se, but jMock is designed to support
object-oriented design and does not work well (and can even be a
hindrance) in testing procedural code.

--Nat

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email