Alex
Thank you for your reply.
"Why not test the class from inside that same class? Why have another
class to test it? "
Although putting tests in main is definitely an option for small
projects, there are advantages to a testing framework in larger projects.
With JUnit, you can use configuration files, the
framework allows for hierarchical testing, and there are a number of
different reporting options. Perhaps there are ways to collate a number of
classes testing via main, but it seems less flexible than the general
testing framework.
"If a class needs considerable structure to test, and a
method will not do, I'd say that's a fair warning that the class needs
more work (i.e., the dreaded Refactoring)."
Good point. Even in JUnitX, the general advice is to only test public,
protected, or package friendly methods. I think the general idea is that,
since no other classes are going to have access to the private methods, why
is there any need to test them?
However, breaking down a complex public method into a small number of
private
methods, especially those that retrieve data structures, enables smaller
test class methods that build on a series of successes in the private
methods' tests
to a successful test of the comprehensive public method. The test method for
the public method ends up much smaller and focused on the aggregate
behavior. This leaves me to wonder if this always points to refactoring or
if there some methods and algorithms that are unavoidably complex and for
which a number of supporting, tested private methods are appropriate?
Tom
