Add Partial JavaBean Mock Implementation

[GoogleCodeExporter]

This is a request to add a JavaBean partial mock implementation to Mockito.
 I've used this for several of my test cases when I needed to maintain some
mock state with JavaBean getters/setters. I figure this would be useful for
others in the Mockito community as well. I've attached a patch with the
simple implementation I've been using for my testing.  Feel free to clean
it up further for inclusion with Mockito.

Original issue reported on code.google.com by trevor.p...@gmail.com on 10 Feb 2010 at 4:38

Attachments:

• ImplementsPartialJavaBean.patch

[GoogleCodeExporter]

Why do you add it as a static singleton? If you reuse the 
ImplementsPartialJavaBean
for multiple mock objects, you'll get strange results:

mock1 = mock(class, IMPLEMENTS_PARTIAL_JAVA_BEAN);
mock2 = mock(class, IMPLEMENTS_PARTIAL_JAVA_BEAN);

assertEquals(null, mock2.getFoo("a"))
mock1.setFoo("a");
assertEquals("a", mock2.getFoo("a"))

I think the Answer-class is nice, but it shouldn't be a singleton.

Original comment by kristofer.karlsson@gmail.com on 12 Feb 2010 at 9:23

[GoogleCodeExporter]

This was a mistake on my part. Originally, I was only testing this with a 
single mock
instance at a time when I submitted this issue. FWIW, I wanted to make the class
available from the top-level Mockito object so I implemented it as a singleton. 
I'll
see if I can slightly rework the patch to handle this.

Original comment by trevor.p...@gmail.com on 12 Feb 2010 at 2:22

[GoogleCodeExporter]

It's a really simple fix - just remove the static instance and replace it with a
static method that returns a new ImplementsPartialJavaBean

Original comment by kristofer.karlsson@gmail.com on 12 Feb 2010 at 2:55

[GoogleCodeExporter]

I'm attaching a patch which allows an instance to be used concurrently from a
singleton scope. The new implementation makes use of a small synchronized block 
with
a WeakHashMap to clean-up partial mocks no longer in use. The WeakHashMap allows
clean-up of stale mock instances. However, it is worth noting that there may be 
some
performance implications in a concurrent test environment if a large number of
partial JavaBean mocks are used. Since, this may be undesirable I am willing to 
drop
the IMPLEMENTS_PARTIAL_JAVA_BEAN singleton field. Alternatively, we could 
convert the
singleton field into a non-singleton factory method (e.g.
IMPLEMENTS_PARTIAL_JAVA_BEAN()).

Original comment by trevor.p...@gmail.com on 12 Feb 2010 at 3:13

Attachments:

• ImplementsPartialJavaBean.singleton.patch

[GoogleCodeExporter]

Agreed, with the simplicity of the fix.  My vote is definitely for a static 
factory
method like you suggested. Though, I would still like to get some feedback from 
the
devs to see what best fits into their code structure.

Original comment by trevor.p...@gmail.com on 12 Feb 2010 at 3:17

[GoogleCodeExporter]

That's really overengineering it.
What's wrong with this?

Your original patch + this:

public static final Answer<Object> partialBean() {
  return new ImplementsPartialJavaBean();
}

Use it with:
mock = Mockito.mock(clazz, partialBean());

No need for weak maps or synchronization.

Original comment by kristofer.karlsson@gmail.com on 12 Feb 2010 at 3:18

[GoogleCodeExporter]

I completely agree the second patch is overkill.  I only provided it as an
alternative. Again, thanks for the feedback!

Original comment by trevor.p...@gmail.com on 12 Feb 2010 at 3:29

[GoogleCodeExporter]

Thanks guys I will look at it! Not sure if it manages to go out in 1.8.3 but I 
will
have an eye on it.

Original comment by szcze...@gmail.com on 14 Feb 2010 at 12:36

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hey guys,
Sorry for looking at it late. Couple of questions:

Why don't you call invocation.callRealMethod() instead of keeping the map of 
bean values?

Original comment by szcze...@gmail.com on 24 May 2010 at 5:31

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 24 May 2010 at 5:31

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Actually this might be interesting for interfaces of beans. I actually don't 
like this style, but I have already seen it several times.

Something like that:

interface ThisKindOfBean {
void setA(String a);
String getA();
}

Service.accept(ThisKindOfBean b);

Original comment by brice.du...@gmail.com on 7 Aug 2010 at 5:25

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 21 Dec 2010 at 10:58

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

This would be a nice enhancement, in my use case I was testing jms and needed a 
mock javax.jms.ObjectMessage. I needed a handful of getters and setters to work 
and I didn't want to implement each individually. The interface is massive so 
creating an actual bean would be tedious. This Answer/patch saved a lot of time.

Original comment by safetytr...@gmail.com on 2 Nov 2012 at 8:15

[GoogleCodeExporter]

Ok, since the ObjectMessage is an interface (not a class) you cannot really use 
a spy. I guess we can add this partial bean implementation, the factory method 
can live under AdditionalAnswers

Original comment by szcze...@gmail.com on 10 Nov 2012 at 5:24