[Bf-committers] Unit testing frameworks
Sat, 7 Jun 2003 13:00:34 +0300
On Friday 06 June 2003 19:35, Dean Giberson wrote:
> Unit testing is a very good thing. I've started using it myself for
> small projects and it makes a big difference. I know that you mention
> unit tests for you code, does that mean a separate project or a
> sub-project within bf-blender?
I meant writing tests for the main Blender code that I might add/change, not a
separate project. I have no concrete examples of changes yet because I wanted
to get this cleared up before I get coding ;)
> I'm afraid of a couple things with adding it in after the fact though:
> 1) Getting everyone to use it & keep the tests up to date, it's been my
> finding that adding tests after the fact does not instill confidence in
> the code unless the next two point are addressed.
Tests might not give us 100,0% confidence in the code but at least we will
know for sure if/when the tested parts will break.
> 2) Code coverage is not complete. When your writing units as you go, you
> tend to understand the corner cases of your code better. So tests get
> written to catch them. In cases where you add tests after the fact, some
> of that 'project lore' may have been lost. To get everyone to trust the
> tests & keep them in sync with the code you need to show that all
> possible paths in a function & all corner cases are tested. For this a
> test coverage tool is also helpful. An example coverage tool would be
> COVTOOL (http://covtool.sourceforge.net/).
I understand that this is a big problem but what is worse, having a few tests
or having no tests at all?
Having all tests pass doesn't mean that you have not broken anything (because
not everything is tested and the existing tests might be flawed). But at
least you'll notice that you have broken something when existing tests start
> 3) Unit tests _must_ be part of the build process for all coders or the
> coverage will not be complete.
> Sorry to be the negative one here but I just want to bring some of my
> experience to the table.
You're not negative, you just happen to raise many very good points which need
to be discussed.
> Also while cutest is good for C, CppUnit
> (http://cppunit.sourceforge.net/) may be better for the bf-blender
> project since it has some C++ components.
The reason why I only looked into unit testing frameworks for the C language
is that you can use them from both C and C++. You can't really do that with
CppUnit. Besides, CuTest is so simple that it'll be easy to get rid of it if
it turns out that it (or unit testing in general) doesn't work well enough
for the project. ;)
noid @ #blendersauce