VerificationData contained in internal package, but accessible via public API

[GoogleCodeExporter]

What steps will reproduce the problem?
The class org.mockito.internal.verification.api.VerificationData is contained 
in an internal package. But this class is used in 
org.mockito.verification.VerificationMode. Therefore it is not possible to 
implement Verification mode in an osgi enviroment and use that implementation.

What is the expected output? What do you see instead?
VerificationData should be moved to an exported package. I suggest 
org.mockito.verification.

What version of the product are you using? On what operating system?
version 1.9.0, osgi enviroment, Java 1.7 Update 7

Original issue reported on code.google.com by Andreas....@mgm-tp.com on 26 Sep 2012 at 2:45

[GoogleCodeExporter]

Hi,

Thanks for the info.
By the way it still is true in 1.9.5-rc1.

Original comment by brice.du...@gmail.com on 27 Sep 2012 at 12:14

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

[GoogleCodeExporter]

Is there any chance that this will be fixed in the release of 1.9.5?

Simply moving the class VerificationData into an exported package is not 
possible, because it would break existing implementations of VerificationMode.

Original comment by Andreas....@mgm-tp.com on 1 Oct 2012 at 7:47

[GoogleCodeExporter]

Exposing VerificationData is not planned before 2.0. As you mentioned - it's 
going to break some existing functionality (unless we figure out how to do it 
without breaking it).

Original comment by szcze...@gradle.biz on 1 Oct 2012 at 8:02

[GoogleCodeExporter]

Here is my suggestion on how not to break existing functionality:

Create a new Interface that has the same responsibility as VerificationMode now 
(lets call this VerificationMode2 for the moment). This will also have a method 
verify. But it will take a parameter VerificationData2, which is a osgi 
publicly available version of the existing VerificationData. Now the only thing 
that mockito needs to provide is an implementation of the already existing 
VerificationMode that adapts an instance of a VerificationMode2 instance.

It is not required to provide overloads for the VerificationMode2 interface in 
the class Mockito or any other mockito classes. If users use additional 
VerificationModes they are likely to adapt the mocktito style by providing 
static methods in their own classes, so that they are able to adapt from 
VerificationMode2 to VerificationMode in their static methods.

Naming is a very difficult problem here, since there are 2 interfaces with the 
same responsibility. So this might cause confusion for users.

Hope this is not too confusing.

Original comment by Andreas....@mgm-tp.com on 1 Oct 2012 at 3:42

[GoogleCodeExporter]

I tried to implement my above suggestion, but failed. The problem is that 
VerificationMode not only depends on VerificationData but also on other classes 
from internal packages. That would mean duplicating much more functionality 
that is already contained in internal packages.

Original comment by Andreas....@mgm-tp.com on 10 Oct 2012 at 11:53

[GoogleCodeExporter]

Hey Andreas,

Thanks for giving it a try. We will have to chip away those internal types one 
by one and eventually get the verification api public. Let us know if you want 
to be involved in some way :)

Cheers!

Original comment by szcze...@gmail.com on 12 Oct 2012 at 6:46

[GoogleCodeExporter]

First it would be good to know, if you are willing to use this issue for 
implementing the public verification api in a later version or you will create 
a new issue.

For the reasons I've have created the issue:
I wanted to implement a VerificationMode that verifies that a method taking one 
parameter has been invoked with a set of parameters in a particular order. 
Something like:

verify(mock, invokedWith(a,b,c)).foo(any())

Since this can also be implemented with existing mockito functionality (it's 
just some more duplications in the code) I wouldn't mind if we would close this 
issue and point to the issue for implementing the public verification api.

I don't know if I will have time for more involvment in that, since I just used 
mockito for a small tool that uses osgi I was developing. Normally I stick with 
jMock. But I will watch the issue for the implementation of the public 
verification api and drop my two cents if they are useful.

Original comment by Andreas....@mgm-tp.com on 12 Oct 2012 at 7:09

[GoogleCodeExporter]

I'd rather the effort of publicizing the api was driven by a use case. If the 
use case can be solved differently I would probably not prioritize it high for 
now. Let's keep this issue open for now.

Thanks for input!

Original comment by szcze...@gmail.com on 12 Oct 2012 at 7:19

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