Running unit tests under valgrind

[John Ralls]

On May 21, 2012, at 1:42 PM, Christian Stimming wrote:

> Am Montag, 21. Mai 2012, 13:30:11 schrieb John Ralls:
>> On May 21, 2012, at 11:36 AM, Phil Longstaff wrote:
>>> I already found one memory leak and one uninitialized variable when
>>> running the libqof/qof unit tests under valgrind.  Can we set up all
>>> unit tests to run with valgrind automatically?
>> I don't think we want to impose the performance hit for doing that by
>> default: Unit tests need to run quickly so that they're used after every
>> change. A 20X slowdown would mean that nobody would use them.
>> 
>> What's more, ISTM leaks in unit tests aren't a big deal anyway. Unit test
>> programs are small and exit almost immediately. A leak will do no harm at
>> all. (Some of the "make check" tests are another matter entirely.)
>> 
>> As for uninitialized variables, the compiler will find those if you build
>> with -Wall -Werror. No need to take Valgrind's performance hit for that.
> 
> I think Phil's suggestion is a very valid idea in order to find memory leaks 
> inside the functions that are being tested. On the other hand, I agree with 
> Derek and John in that using valgrind doesn't make much sense as a default 
> when running the unittests. Hence, I think it would be good to provide some 
> infrastructure for optionally running the tests with valgrind. But it 
> shouldn't be added as a normal testing step that needs to be performed by 
> everyone who is running the tests.

OK, though a leak in a unit test doesn't necessarily mean that the application leaks, nor does the absence of a leak in the unit test guarantee that the application doesn't leak. 

Regards,
John Ralls