[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