Unit testing using logs

[Vincent Hennebert <vi...@anyware-tech.com>]

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

Re: Unit testing using logs

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: Unit testing using logs

[Andreas L Delmelle <a_...@pandora.be>]

On Mar 19, 2007, at 15:49, Vincent Hennebert wrote:

> <snip />
> Does that make you feel any sudden urge to shout? ;-) Any thoughts?

Hmm, it would indeed be a bit cheap... :/

Seriously, since we're still looking for a nicer way of separating  
end-user info- and error-handling and developer debug-messages, maybe  
this is a good starting point for a discussion.
The cleaner, better --more expensive :(-- way in the long run, I  
guess, would be to start designing a way to plug in custom handlers/ 
listeners that the private methods can talk to, if one or more are  
registered.

A UnitTestListener could then be given a String to compare, but also  
more conveniently, you could design a standard LayouManagerTestInfo  
baseclass, that can be used to pass much more info about the internal  
state to the testing class.

You would do your tests much as you do know: build a small FO tree,  
and plug in a custom FOEventHandler to control the LM creation.  
Register your Listener, run the LM's public methods with values of  
your choice. The public methods will call the private methods, that  
will register events on your Listener.


Cheers,

Andreas