Running unit tests under valgrind
donaldcallen at gmail.com
Mon May 21 18:41:59 EDT 2012
On Mon, May 21, 2012 at 6:22 PM, Phil Longstaff <phil.longstaff at yahoo.ca> wrote:
> Yes. A lot of the leaks are in the unit test code. But I've found 2 legitimate leaks as well.
Do you guys run the whole system under valgrind (John is obviously
right about tests on the parts don't necessarily say anything about
the whole) prior to release as part of your QA process?
> From: John Ralls <jralls at ceridwen.us>
> To: Christian Stimming <christian at cstimming.de>
> Cc: gnucash-devel at gnucash.org; Phil Longstaff <phil.longstaff at yahoo.ca>
> Sent: Monday, May 21, 2012 4:56:52 PM
> Subject: Re: Running unit tests under valgrind
> 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.
> John Ralls
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel