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

[bf-committers@blender.org]

On Mon, Feb 24, 2003 at 01:25:49PM +0200, Timo Mihaljov wrote:
> 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.

While human testing will always be necessary, I still think this sort of
testing could and should be automated. For the example above, with
antialiasing, this could be tested by rendering a short line segment
(e.g. 4 pixels) with a pure white color into a tiny render window
(say 8x8 pixels). The test could check to see if any grey pixels are
present. If so, antialiasing must be working. A more rigorous test
could check the position and values of the grey pixels. An extremely
rigorous test could then print the mathematical deviation of the
antialiasing based on various sampling models.

This way, if you are making a change to the file loading dialog, and
suddenly the antialiased-line test no longer passes, you know that you
screwed something up - maybe you accidentally deleted a single character
in the antialiasing file without realizing it, or maybe you changed a
global #define which subtly affected how the antialiasing code works, or
maybe you are globally overwriting memory, etc. One purpose of the tests
is to catch unintentional side effects in distant, unrelated, other parts
of the code. Automating as much testing as possible is good from a QA
point of view - but it requires time and discipline to keep the tests
up to date. In the Extreme Programming (XP) philosophy, however, you should
write the automated test before you even begin coding any new features -
the test then is the executable and 100% explicit acceptance criteria to tell
you when you are done coding. The test case should be the definitive and
complete statement of what a piece of code must/must not do. XP isn't a
panacea, but it has several good ideas. "Test first" is one of them.

> 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.

Right. For instance, for stuff like armatures you could have a test which
initializes itself by calling the functions to create an armature with
e.g. certain IK constraints, then the test itself would move the effector
(by calling the appropriate functions), and it would then check if the 3D
position of the other parts of the armature are where they should be. Little
or no GUI action is needed to test these sorts of things.

-Norman