One thing that I think could be mighty interesting, but I've never tried it, is to use reflection in a unit test to exercise private methods. I think that this might be able to be made simple enough to be okay ...
Originally posted by Roger Chung-Wee:
In my project team, we've been using PrivilegedAccessor to test private methods by means of reflection.
Originally posted by Paul Wheaton:
In fact, I think if people walk away from the article knowing that there is a difference between unit tests and functional tests our world will be a much nicer place![/QB]
When I get to the point that I have a rich suite of tests, and my test class names all end with "Test", then my IDE makes twice as many suggestions as I want it to. When my test class names all start with "Test", my IDE makes exactly the right number of suggestions.
Not only is this calling other business logic, it's calling an application server! Possibly across a network! Thousands of these are gonna take more than ten seconds. Plus, changes in the EJB stuff could break my tests here! So a mock object needs to be introduced.
If I could just mock out all of the EJB stuff, I'd be sitting pretty. Hmmmm .... If the code were to somehow get my mock FarmEJBRemote, I'd be in fat city.
First, to create the mock. If FarmEJBRemote were a class, I would extend it and override all the methods. But since it happens to be an interface, I'll just make a fresh class and implement all the methods:
If you are a good OO engineer, you should be hopping mad right about now! Oh sure, violating encapsulation in unit test code is mighty uncomfortable, but violating encapsulation in production code JUST AIN'T DONE!