We tackled this using a "hack-ish" CMake command for Google Tests that found all our tests in the source code, and generated CTest commands for them. You could do a similar thing on a test suite. Details are here:
http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test -dan On 9/20/09 10:40 AM, "Wojciech Migda" <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Philip Lowman pisze: >> You could split up your testcases into multiple CxxTest classes. >> >> You could check to see if the cxxtest code generator supports >> preprocessor statements in generating test runners. Then you could >> group your tests by #ifdef / #endif...? Alternatively if it's not >> supported you may be able to modify the code generator to output >> multiple runners depending on the tests you want to run, e.g. >> cxxtestgen.pl --enable-test foo >> >> I think splitting things up probably would be the easiest approach. >> >> >> On Sun, Sep 20, 2009 at 10:01 AM, Wojciech Migda >> <[email protected]> wrote: >> >> Hi all, >> >> I was wondering about an improvement for the way CxxTest unit tests >> are coupled with CTest. Right now when CTest submits results to >> CDash the tests are counted by binaries executed. In my unit tests >> each binary corresponds to an entire suite (approx. 150 testcases >> grouped within single CxxTest class). I'd see it very useful to >> have CTest operate with CxxTest based unit tests on a testcase >> level. Has anyone stumbled upon similar problem and got ideas / >> solutions ? >> >> Thanks for assistance, >> >> -Wojciech >> > Indeed, splitting is the easiest approach, albeit it adds additional > effort - when a new test is added to a suite CMakeLists.txt has to be > updated accordingly. > > If my idea how CTest works when it uploads results to CDash is correct > then it only looks at the return code of the executed binary and > captures its output. What if there was an option for CTest to work in > a multiple-testcases mode where the output returned by the executed > binary would be formatted in a way so as CTest would be able to parse > it and process into CDash xml files with information on all tests > executed. Just a thought, I have no idea how complicated that would > turn out to be. > > I also thought about the binary itself being able to run single > testcases on the basis of command line arguments, but that would > require parallel information being stored in CMakeLists.txt, which > again add effort. > > I'll see if I have more ideas. > > Thanks, > > - -Wojtek > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFKtkz70iFl+nAyImcRAsPSAJ4yMjKSb96NZ02awttzwwu/nHZRhgCfQ2KZ > VEM63SdgrUUA4OIXGApKJd8= > =4utB > -----END PGP SIGNATURE----- > > > ---------------------------------------------------------------------- > Bezplatne konto i limit do 100 tys. Otwierasz? > http://link.interia.pl/f2342 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Daniel Blezek, PhD Medical Imaging Informatics Innovation Center P 127 or (77) 8 8886 T 507 538 8886 E [email protected] Mayo Clinic 200 First St. S.W. Harwick SL-44 Rochester, MN 55905 mayoclinic.org _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
