Verify protected method call

[jchrisder]

Hi, sorry if it is a stupid question, but is it possible to verify a
protected method has been called?

[jchrisder]

[Johan Haleby]

Hi, 

Yes it's possible. If possible move the test to the same package as the protected method which means that you can invoke it normally. Otherwise you can make use of verifyPrivate in PowerMock.

/Johan

On Wed, Nov 24, 2010 at 1:01 PM, jchrisder <jc.de...@gmail.com> wrote:

Hi, sorry if it is a stupid question, but is it possible to verify a
protected method has been called?

--
You received this message because you are subscribed to the Google Groups "PowerMock" group.
To post to this group, send email to powe...@googlegroups.com.
To unsubscribe from this group, send email to powermock+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/powermock?hl=en.

[Jean-Christophe DEROUET]

No, I had to add that this is not possible currently to move test in the same package as the tested class, but ok now I understand I can use verifyPrivate also for protected method, thanks a lot

2010/11/24 Johan Haleby <johan....@gmail.com>

[Johan Haleby]

You can use verifyPrivate for public methods as well if you like (but you would probably never like that :)). verifyPrivate more or less just helps you invoke a method using reflection.

/Johan

[Hilco Wijbenga]

On 24 November 2010 06:00, Jean-Christophe DEROUET <jc.de...@gmail.com> wrote:
> No, I had to add that this is not possible currently to move test in the
> same package as the tested class, but ok now I understand I can use
> verifyPrivate also for protected method, thanks a lot

Just curious ... why not? I don't see how anyone or anything could
prevent you from putting a *test* class in the same package as the
class under test. I always do this.

[Jean-Christophe DEROUET]

I do not say that this is not possible, but simply it is an architecture choice on our application down here, we do not want to mix production code and test code at the same place (a package for test class, a package for real class).

2010/11/24 Hilco Wijbenga <hilco.w...@gmail.com>

--

[Jean-Christophe DEROUET]

I would add that this application inherit a lot of legacy code with a lot of custom mock objects used in in old-fashioned junit test. This would be re-write one day, but for now we have to manage this history

2010/11/24 Hilco Wijbenga <hilco.w...@gmail.com>

--

[Hilco Wijbenga]

On 24 November 2010 09:01, Jean-Christophe DEROUET <jc.de...@gmail.com> wrote:
> I do not say that this is not possible, but simply it is an architecture
> choice on our application down here, we do not want to mix production code
> and test code at the same place (a package for test class, a package for
> real class).

Even though that's a best practice? To be clear, we're talking about
using the same *package* not the same *directory*:

src/main/java/org/example/TheClass.java

src/test/java/org/example/TheClassTest.java

so there is no mixing of test and production code. This really makes
testing easier because you have access to protected and package
private methods/members.

[Hilco Wijbenga]

On 24 November 2010 09:05, Jean-Christophe DEROUET <jc.de...@gmail.com> wrote:
> I would add that this application inherit a lot of legacy code with a lot of
> custom mock objects used in in old-fashioned junit test. This would be
> re-write one day, but for now we have to manage this history

Count yourself lucky ... at least you *have* some unit tests. I had to
maintain a mountain of legacy code with just 5(!) unit tests. And none
of them worked. :-)

[Johan Haleby]

Hi, 

The reason why you want to avoid using verifyPrivate for public (and preferably for protected methods as well) is that it's not as refactor-friendly as invoking a standard method. This makes your test harder to maintain if you make changes to your production code. 

/Johan

--