[Bf-committers] Code "cleanups" in buttons.c

Timo Mihaljov bf-committers@blender.org
Mon, 24 Feb 2003 13:25:49 +0200


On Sunday 23 February 2003 22:32, bf-committers@nlin.net wrote:
> An additional note to my last message -
>
> On Sun, Feb 23, 2003 at 10:25:20PM +0200, bf-committers@nlin.net wrote:
> > I imagine it's kind of tricky, because lots of what needs to be
> > tested in Blender is of a graphical nature - but I am still convinced
> > that such testing can be fit into a testing framework and thus automated.
>
> A useful starting point for GUI testing might be
>
> http://c2.com/cgi/wiki?GuiTesting
>
> -Norman

At first I'd like to point out that my experience in writing unit tests is 
very limited (I've started using them only quite recently in a small project), 
so my opinions about the subject are the ones of a layman.

It's a good thing you brought testing up, as it is a very important matter to 
discuss (another one would be profiling, but that subject deserves it's own 
thread). I looked at the documentation of some unit testing frameworks (I 
didn't have the time to actually try them out yet, I'll do that later today) 
and Check (http://check.sourceforge.net/) looks very promising (but seems to 
be unix only).

GUI testing is a bit more problematic. I for one would not trust automated 
tests for graphical output, as there often is no fixed correct output. A test 
can't tell if changes are good or bad. If someone adds anti-aliasing to a line 
drawing function the output will be different (which the test suite will
see as a bug), while the change is actually a positive one. It also seems to 
me that graphical erros would be spotted more quickly and efficiently by 
people testing the software.

I also think that all the actions could be tested non-graphically by having 
the test suite generate a bunch of events and check the program's responses 
to them.


_noid