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

Reply via email to