Add "serializable" to @Mock Annotation

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a test case using Mockito
2. Create a @Mock object
3. Attempt to serialize it in java

What is the expected output? What do you see instead?
It's not possible to make a @Mock Object mock serializable into annotation like 
it is with Mockito.mock(Object.class,withSettings().serializable())

What version of the product are you using? On what operating system?
1.9.0

Please provide any additional information below.
I cloned repo and commited a patch in this commit : 
http://code.google.com/r/ludovicmeurillon-mockitopatches/source/detail?r=0575df7
a085a7dfe4d726d789627c723950d1146 

Feel free to merge it with codebase as soon as you think it's correclty 
implemented and tested.

Original issue reported on code.google.com by ludovic....@gmail.com on 1 Oct 2012 at 8:54

[GoogleCodeExporter]

Hi,

Thanks a lot for your submission Ludovic. 

I don't know if adding settings this way is scalable. What if all setting or 
new ones are promotted in the annotation, it will clutter the annotation 
configuration. I think it might need some team consensus or direction at least.

Also the creation of settings from the annotation might not scale well too if 
more settings are to be added, I'm not a huge fan of ifs in general (long live 
Erlang ? ;)).

In the mean time if you are using @InjectMocks, you might want to upgrade to 
1.9.5 as the injection engine scans for mocks created with the MOckito.mock() 
method.

Anyway your pull request is pretty good, with tests, underscored method names, 
that rock.

Original comment by brice.du...@gmail.com on 1 Oct 2012 at 9:56

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

[GoogleCodeExporter]

I don't mind pulling this. It's adding more stuff to annotation api but it is 
consistent with the regular java api so it's not strictly 'new' thing. Is it 
possible to use the withSettings() directly in the annotation?

Brice, you're sort of an owner of annotation / injections stuff :) Do you think 
we should pull it?

Thanks for the patch - looks very nice!

Original comment by szcze...@gradle.biz on 2 Oct 2012 at 6:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Brice,

thank you for your quick answer.

To design a great annotation API (and fully consistent with the traditionnal 
Java API), it is also possible to create other Annotations (like @Settings(...) 
for example) and process them the same way Mockito process @Mock annotation

You could have for example :

@Mock 
@Settings(extraInterfaces={Anyway.class}, serializable=true) 
Type mock;

or a deeper annotation implementation :

@Mock 
@Serializable 
Type mock;

Are those example more scalable in your opinion ?

Original comment by ludovic....@gmail.com on 2 Oct 2012 at 7:11

[GoogleCodeExporter]

@Szczepan Nope the annotation attributes only allow values that can go in the 
class constant pool, which means primitive values, Strings, enums and classes 
(and arrays of the previous types)
That's the "issue" with the annotations.

@Ludovic Thanks for the ideas, I'll keep it in mind. Maybe Szczepan is right. 
Still while adding only one setting value is not much right now and certainly 
look reasonable considering the few values already there, if we keep it this 
way it might be more messy in 100 years ;)

Using @Settings is appalling me.

What's your thought on the matter Ludovic

Original comment by brice.du...@gmail.com on 3 Oct 2012 at 8:44

[GoogleCodeExporter]

@Brice I agree with you on situation in 100 years if you put all setting stuff 
directly into @Mock annotation.

Creating this issue, I just pointed out the fact that as developers we cannot 
do the same things with annotations that we can do with simple static Java API.

I know that all settings problems that need real instances (answers etc..) 
cannot be adressed by java annotations but I think that if you can align 
Annotation API and Procedural API on some points, it will be more clear for all 
of us.

Original comment by ludovic....@gmail.com on 3 Oct 2012 at 1:33

[GoogleCodeExporter]

OK, and in the following 100 year, we deprecate an API in favor of soemthing 
else, say in version 42.0.0.

After these couple of days, I'm leaning to think this as a reasonnable addition 
to @Mock.

Original comment by brice.du...@gmail.com on 3 Oct 2012 at 10:30

[GoogleCodeExporter]

I took time to think about it, and I'll accept this pull request, I'll try to 
merge it this week.

Original comment by brice.du...@gmail.com on 9 Oct 2012 at 9:36

• Changed state: Accepted

[GoogleCodeExporter]

OK don, it's on master now : 
https://github.com/mockito/mockito/commit/d8b18f2e77c3f352677a6993225c4333b98d04
81

Original comment by brice.du...@gmail.com on 23 Oct 2012 at 9:34

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 27 Nov 2012 at 5:11

• Added labels: Serialization

[GoogleCodeExporter]

I wanted to use this feature, but can't find it anymore in 
<http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mock.html>. Was it 
removed again from @Mock?

Original comment by marcus.b...@googlemail.com on 20 Mar 2014 at 5:38

[GoogleCodeExporter]

No the feature wasn't never in a public release. It's there on github though ;)

Original comment by brice.du...@gmail.com on 20 Mar 2014 at 8:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

That's a pitty. My tests would look much prettier with it. Shall I provide some 
detail on my use case or isn't there any chance to get this into a release?

Original comment by marcus.b...@googlemail.com on 21 Mar 2014 at 10:50

[GoogleCodeExporter]

I wasn't saying that it will never be in a public release, but that the feature 
isn't yet shipped in a public release ;)
It will be in the next release, now the question is to polish the future 
release of mockito to make it happen. And there's still much to do.

Original comment by brice.du...@gmail.com on 21 Mar 2014 at 11:21

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 16 Aug 2014 at 2:43

• Added labels: Milestone-Release2.10.1

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 24 Aug 2014 at 3:14

• Added labels: Milestone-Release1.10.1
• Removed labels: Milestone-Release2.10.1

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 24 Aug 2014 at 3:50

• Added labels: Milestone-Release1.10.0
• Removed labels: Milestone-Release1.10.1