Originally posted by Frank Carver:
Ilja wrote: It's ugly, but certainly better than not writing a test...
I'm not entirely sure about that either. I really don't like delivering test code in a deployed system, I'd sooner make something public, or make it "package" scope and put a test in the same package, than put test code in delivered system.
Give that by your own admission, this is only used when the design of the class is still very unstable, I'd accept the hit of needing to alter the tests with the code in preference to the worry of remembering to remove test-specific code after the design stabilises (whenever that might be).
Originally posted by Eduard Jodas:
Have you ever tried AspectJ?
I haven't, but from some articles it seems it is perfect for your test needs.
I think a step I would like to see next is something discussing agility in code. After all, exposing otherwise private data and with the wrong kind of unit tests, you can make code very brittle (difficult to change). It seems we need better understanding of how to have good testing *and* have agile code.
Originally posted by Steve Fahlbusch:
For the internal tests like you have described, I
set all "private" methods to default. I then
create a TestClassA class that performs the wanted
tests against ClassA.