This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
When I got my MS twenty years ago, object-oriented was all the rage and UML was still a ways off. Software testing was in its infancy and no one (AFAIK) had even thought of dependency injection. Can you give any insight on software testing and object-oriented thought? For example, something I puzzle over is the balance encapsulation via private members and methods with the need to access these methods from JUnit tests.
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, Doctor Faustus (v, 121-24)
There is a lot of discussion on abstract and concrete classes and how you can dynamically load classes, but not as it pertains directly to dependency injections. I do go through a lot on the process of developing and testing applications, but not with any specific approach.
My take on it is that if you need to access private members and methods to run your unit tests, you're usually doing it wrong. Tests should be based on the public interface of components. Otherwise you're tying your tests too closely to your implementation, making change and refactoring far more painful than they should be.
Joined: May 01, 2013
This is one of the most interesting debates regarding OO. From the beginning the premise was that all data possible should be private. In fact, perhaps all data should be private and only accessible via accessor methods (or properties).
I totally agree that you shouldn't change anything for testing purposes. It's kind of like the uncertainty principle. How can you test things if you have to change them to test them!