Testing private methods

[VMurthy]

Hi

Can an annotation be added for testing private methods. This must be able to allow private methods to be tested during testing phase but yet not be publicly accessible in the distribution jar.

Thanks
Venkatesh

[Reinier Zwitserloot]

How would that work? We can only modify source code. We could let you write private methods where all that '@TestAccessible' does is remove 'private', but a comment (and leaving off 'private') seems a lot less convoluted.

Please show in vanilla java a 'pre' and 'post' treatment if you have something in mind.

[Fabrizio Giudici]

On Tue, 10 Jun 2014 12:10:53 +0200, Reinier Zwitserloot
<rein...@gmail.com> wrote:

> How would that work? We can only modify source code. We could let you
> write
> private methods where all that '@TestAccessible' does is remove
> 'private',
> but a comment (and leaving off 'private') seems a lot less convoluted.

Agreed. For the comment thing, Guava has got the @VisibleForTesting
annotation.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Martin Grajcar]

On Tue, Jun 10, 2014 at 12:22 PM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

On Tue, 10 Jun 2014 12:10:53 +0200, Reinier Zwitserloot <rein...@gmail.com> wrote:

How would that work? We can only modify source code. We could let you write
private methods where all that '@TestAccessible' does is remove 'private',
but a comment (and leaving off 'private') seems a lot less convoluted.

Agreed. For the comment thing, Guava has got the @VisibleForTesting annotation.

Agreed, except for two notes:

- The meaning of @VisibleForTesting is underspecified. It only says that the annotated thing is more visible in order to allow testing, but it says nothing about what the "normal" visibility should be. As the declared visibility is usually "default", this is rarely a problem as it leaves a single possibility.

- There's nothing preventing you to misuse the extended visibility in normal code. But this is rather something for a tool like findbugs.

I guess, Lombok could provide a better solution, e.g.,

sneakyAccess(someObject).somePrivateMethod()

(or even allowing the calls in tests automatically) , but I'm afraid, it's not worth the effort. The main advantage would be the IDE not offering such methods in normal code.

[Fabrizio Giudici]

On Tue, 10 Jun 2014 12:46:56 +0200, Martin Grajcar <maaar...@gmail.com>
wrote:

> Agreed, except for two notes:
>
> - The meaning of @VisibleForTesting is underspecified. It only says that
> the annotated thing is more visible in order to allow testing, but it
> says
> nothing about what the "normal" visibility should be. As the declared
> visibility is usually "default", this is rarely a problem as it leaves a
> single possibility.
>
> - There's nothing preventing you to misuse the extended visibility in
> normal code. But this is rather something for a tool like findbugs.
>
> I guess, Lombok could provide a better solution, e.g.,
>
> sneakyAccess(someObject).somePrivateMethod()
>
> (or even allowing the calls in tests automatically) , but I'm afraid,
> it's
> not worth the effort. The main advantage would be the IDE not offering
> such
> methods in normal code.

Agreed on notes too ;-) My point is that in this case an annotation is
only meaningful for documenting and tooling (findbugs, but also a simpler
search in the IDE, given that one might think that methods not private for
test purposes must be kept to a minimum - often a refactoring helps - and
could be subject of a periodic code review.

For this reason not only I don't see a plus in something like
sneakyAccess(someObject).somePrivateMethod(), but it's a problem IMHO: I
prefer to *know* that somePrivateMethod() is accessible for testing,
because this documents a potential, smaller problem.