I'm not comfortable with using log output for unit testing. You'll discover incompatible changes in the code only at runtime, not at compile-time. As Andreas suggests, there should be better ways even if it means that the initial effort may be a little bigger. As an example, look at the ElementListObserver in the layoutmgr package which I created for unit testing.
On 19.03.2007 15:49:26 Vincent Hennebert wrote: > Hi, > > Again I'd like to share my thoughts. I've been looking for a while for > a means to unit-test the layout code. There are two difficulties > I think: > - re-creating the necessary LayoutManager structure. While it would be > great to be able to create only the necessary LMs (e.g., TableLM and > its children), it isn't necessarily possible because of property > inheritance or contexts for computing percentages. There might be > tricky side-effects difficult to track. > - unit-testing private methods; that would be unfortunate to break > encapsulation just to be able to test the outcome of some methods. > > Thus I was thinking about using logs for testing purposes. We would have > a custom logger that instead of printing out the message would compare > it against an expected string. > Granted, that's really not elegant and also not very robust (String > comparisons). But that would allow to perform unit testing quite easily, > without breaking design, and for cheap. > > Does that make you feel any sudden urge to shout? ;-) Any thoughts? > Thanks, > Vincent Jeremias Maerki
