• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Private methods in TDD

 
Anton Shaikin
Ranch Hand
Posts: 65
IntelliJ IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recently I started learning test-driven development, and so far I like most of the ideas that form this approach.
It's quite easy to follow most of the tutorials I found, and I feel that I'm starting to get the hang of it.
But I'm also thinking about whether I willbe able to apply it on my job. The problem is as follows.

We use JMS in our application to communicate with partner systems.
As soon as a message from a partner system arrives, the corresponding message-driven bean performs some checks and delegates further processing of the message to some EJB. Almost all EJBs have one public method which is implemented in the following way:

All the other functionality is hidden inside private methods of that same EJB implementation class.
Now, I know that you're probably going to say, that it's a bad design, and such...
But I joined the project when most of the stuff was written in such a way, so I'm kind of forced to deal with that.
Considering all the above, is it okay to test private methods in my case?

I would appreciate any opinions.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34860
369
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anton Shaykin wrote:Considering all the above, is it okay to test private methods in my case?

Yes. I would make them package private (default) access rather than trying to call a private method for clarity, but both ways are ok.
 
Anton Shaikin
Ranch Hand
Posts: 65
IntelliJ IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeanne!
Your opinion is very much appreciated.
 
Tejas Aryan
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Other option is to move the business logic from ejb method to another method (public or package private) and test that method.
 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We can test private methods also using reflection API.

check this link
 
Anton Shaikin
Ranch Hand
Posts: 65
IntelliJ IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gaurav Swaroop wrote:Other option is to move the business logic from ejb method to another method (public or package private) and test that method.

Can't do that. The project is pretty old and I don't really want to violate its evolved coding style.

Prabhakar Reddy Bokka wrote:We can test private methods also using reflection API.

Yeah, I know. But the question wasn't about how to test private methods, but about whether it's a good practice.

Thanks to all anyway.
 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes. Definitely its a good practice.

The 'Thumb Rule' of Junit is to Test the business logic where ever it present.
It may be in private method or private constructor or anywhere.

 
Anton Shaikin
Ranch Hand
Posts: 65
IntelliJ IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prabhakar Reddy Bokka wrote:Yes. Definitely its a good practice.

Well, many would disagree. I read many articles on TDD that say that you should only test your public interface.
 
Prabhakar Reddy Bokka
Ranch Hand
Posts: 197
Java Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anton Shaykin wrote:Well, many would disagree. I read many articles on TDD that say that you should only test your public interface.


Thats correct. do not confuse with TDD and JUnit.

TDD approach itself different. In the TDD you write the test case first and then start writing your business logic to make your test case pass.

If you are writing JUnit tests for existing code, it could not be TDD approach.
 
Anton Shaikin
Ranch Hand
Posts: 65
IntelliJ IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
do not confuse with TDD and JUnit.

I guess by JUnit you meant unit testing in general. If so, then I don't. The question was exactly regarding TDD. By given example I just showed how business logic is implemented in our project. I wasn't going to use TDD for existing code. That would be test-driven refactoring though, which also has a right to exist.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic