This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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 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.