• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

Private methods in TDD

 
Ranch Hand
Posts: 65
IntelliJ IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author & internet detective
Posts: 41250
849
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jeanne!
Your opinion is very much appreciated.
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 198
Oracle Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 198
Oracle Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 198
Oracle Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Oh the stink of it! Smell my tiny ad!
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic