The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

mikemil (27) [Avatar] Offline
#1
Just got the book and read thru chapter 8 so far. I bought the book to help provide more 'ammunition' when I complain about the lack of testing on my current product. The project is an EJB2 project and so most of our JUnit tests are actualy the 'integration unit tests' mentioned in Chapter 7.

Sorry if this is covered later in the book but I really wanted to ask this now - it seems like the book covers testing of public methods. What's the general consensus on testing of protected and/or private methods. Most of our devs create private methods within their classes - so should we be guiding them towards making those protected so that those methods could be tested by a test case in the same package? Or possibly, create new class the extends that class just for the purpose of testing?

Thanks for the insight!
felipe.leme (18) [Avatar] Offline
#2
Re: General question
Hi there,

> What's the general consensus on testing of protected and/or private methods.

In theory, you should not be concerned about private methods, and test only the public methods that call them. Practically speaking, there are cases where you're forced to have too many private methods and should test a few of them in isolation...

> so should we be guiding them towards making those protected so that
> those methods could be tested by a test case in the same package?

Yes, that is a good approach. In fact, I do that a lot, and even add a "// not private because it's used by test cases" comment do document it. But that's not necessarily a general consensus.

If you are not able to change the method signature, you could still access it through reflection. Chapter 19 discuss this approach, and even though it focus on private attributes, the same techniques could be used on methods.

> Or possibly, create new class the extends that class just for the purpose of
> testing?

That's a possibility too, but I try to avoid it because you end up testing a derived object, not your original class. Besides, if the method is private, your sub-class won't be able to access it anyways.

-- Felipe (co-author)