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. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers