[Bf-committers] GSoC Proposal: Unit Testing

Brecht Van Lommel brecht at blender.org
Sat May 8 11:26:12 CEST 2010


Hi,

I think the direction of this project should also be discussed with
your mentor, but among the summer of code mentors I think we agreed
that it should be python based and not really fine grained unit tests
for C code. Unit testing specifically is not necessarily what we think
is the best idea, if it is the kind of thing that requires a lot of
effort to write and maintain as code changes. We want something that
allows us test as much as possible with as little effort as possible.

Instead you can think of things like:
* Regression testing of renders compared to existing version (compare pixels)
* Same for e.g. mesh tools (compare mesh topology)
* Importers/exporters testing if the result is the same
* Maybe even ecording user operations and then verifying if the result
is the same?
* Verify operators don't crash when run in different contexts
* Testing that using API functions/properties don't crash with various inputs
* Testing for NaN/Inf number results.
* Testing for memory leak error prints.

In fact just based on renders you can test if most modifiers, nodes,
constraints, particle options still work as before. Clearly this is
not as useful as fine-grained unit testing as you usually do with
toolkits like Google Test, but only a testing framework that is simple
and requires little work to maintain will actually be picked up by
developers. This leads a bit more to 'regression testing' maybe, but
many of the things that break can't be expressed easily as assertions
unless you write hundreds of thousands of lines of testing code.

Brecht.


More information about the Bf-committers mailing list