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

bf-committers@blender.org bf-committers@blender.org
Sun, 23 Feb 2003 22:25:20 +0200

On Sun, Feb 23, 2003 at 01:24:02PM +0200, Timo Mihaljov wrote:
> I'd like to reorganize the interface code using refactoring* to make it more 
> modular 
> * refactoring could be roughly described as improving code in small steps 
> (refactorings) without changing what the code does.
> The nice thing about refactoring is that you can stop after any step, and the 
> code will still work just like it should be.

A vital part of refactoring is the usage of unit tests to verify that the
code does, in fact, act exactly the same after the refactoring as it acted
before the refactoring. I don't know what kind of unit testing (in
the refactoring or extreme-programming sense of the word) Blender has,
but it is important to do testing as you do refactoring; in fact, the
tests should ideally exist and be run before, during, and after the
refactoring. Indeed, the very notion of refactoring requires testing to
verify the core refactoring idea - "improving ... without changing what the
code does".

Coincidentally, I was recently looking for some support software for
refactoring in C++ and found some unit testing software at


Maybe this can be of some use.

If you're planning on doing refactoring on the Blender codebase, you (or
someone else) also needs to write the appropriate tests. I see this as a good
thing, since over time the increasing number of unit tests would improve
confidence in the code and make it easier to see if you "broke" anything.
In the refactoring philosophy, running tests should be easy, automatic,
and continuous. In the long term, this would mean that after making any
change to Blender you could do something like "make test" (maybe this
make target is already available?), and have Blender execute, say,
5000 unit tests automatically, write the results to a log file, and you could
then easily see if your change broke anything.

However, for this to be useful on a large scale, the writing of tests
requires some sort of standardized framework. The testing frameworks
listed at the URL above are designed to be exactly this - standardized,
so that all types of tests can be uniformly started, run, logged, etc.
There is support for set up and tear down of tests (creating "fixtures"
or groups of objects which are needed for several common test cases), etc.
I haven't had the time to evaluate the testing frameworks in detail,
but if you are already doing refactoring work, maybe you could look
at some of these or other testing frameworks, do some evaluation, and
post some suggestions to the list about how and with which tools could
be used for the testing part of refactoring in the context of the Blender
codebase.  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.