Re: cppunit -> Google Test migration and old failing tests
[top posting... again] OK, I got a good build thanks to Damjan's further commits. So, yay on this! I made a small change I thought might effect all the Backtraces but, it did not. So I need to investigate this more. On 08/31/2015 01:35 PM, Kay Schenk wrote: > [top posting] > > OK, my problems are not over. This time the build erred out in > slideshow/test. It was odd because the compiles were OK but not the load. > > I am not providing logs for this because something else, rather more > drastic is happening! Here are my config options-- > > ./configure \ > --build=i686-pc-linux-gnu \ > --host=i686-pc-linux-gnu \ > --target=i686-pc-linux-gnu \ > --with-package-format="installed rpm" \ > --disable-ldap \ > --disable-beanshell \ > --with-jdk-home=/etc/alternatives/java_sdk_openjdk \ > --with-junit=/usr/share/java/junit4.jar \ > --with-system-stdlibs \ > --without-stlport \ > --with-java \ > --with-ant-home=/opt/ant \ > --with-dmake-path=/usr/local/bin/dmake \ > --without-ppds \ > > --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz > " \ > --with-lang="en-US zh-CN" \ > --with-perl-home=/usr \ > --disable-directx \ > --enable-dbus \ > --disable-activex \ > --disable-atl \ > --disable-gnome-vfs \ > --enable-verbose \ > --enable-dbgutil \ > --with-x > > normally with this I get about 31MB of output. More info -- > > gcc 4.4.7-16 > gcc-c++ support for above version > libgcc-4.4.7 > libstdc++-4.4.7 > > > Now, I am getting a HUGE amount of backtraces -- sample included here > (this same error repeats a million times or so it seems). So my output > file is about 10x the size it usually is! > > > .Error: File > /home/kschenk/AOO_source/openoffice/trunk/main/sal/cpprt/operators_new_delete.cxx, > Line 91: operator delete mismatch > Backtrace: [0] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/lib/libuno_sal.so.3: > osl_assertFailedLine+0x150 > Backtrace: [1] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x41467 > Backtrace: [2] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x41661 > Backtrace: [3] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > _ZdlPv+0x23 > Backtrace: [4] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > _ZN5boost14checked_deleteIcEEvPT_+0x11 > Backtrace: [5] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x38ce6 > Backtrace: [6] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x371a4 > Backtrace: [7] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x37216 > Backtrace: [8] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x37268 > Backtrace: [9] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > _ZN6Export8CopyFileERK10ByteStringS2_+0x250 > Backtrace: [10] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > _ZN10HelpParser15MergeSingleFileEP7XMLFileR13MergeDataFileRK10ByteStringS4_+0x3e9 > Backtrace: [11] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > _ZN10HelpParser5MergeERK10ByteStringS2_S2_bRKSt6vectorIS0_SaIS0_EER13MergeDataFileb+0x60e > Backtrace: [12] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > main+0x6b0 > Backtrace: [13] /lib/libc.so.6: __libc_start_main+0xe6 > Backtrace: [14] > /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: > ???+0x1c331 > > HELP! > > > > On 08/31/2015 09:12 AM, Kay Schenk wrote: >> >> >> On 08/30/2015 11:52 PM, Damjan Jovanovic wrote: >>> On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic wrote: On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: > > > On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: >> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: >>> >>> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead
Re: cppunit -> Google Test migration and old failing tests
[top posting] OK, my problems are not over. This time the build erred out in slideshow/test. It was odd because the compiles were OK but not the load. I am not providing logs for this because something else, rather more drastic is happening! Here are my config options-- ./configure \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu \ --with-package-format="installed rpm" \ --disable-ldap \ --disable-beanshell \ --with-jdk-home=/etc/alternatives/java_sdk_openjdk \ --with-junit=/usr/share/java/junit4.jar \ --with-system-stdlibs \ --without-stlport \ --with-java \ --with-ant-home=/opt/ant \ --with-dmake-path=/usr/local/bin/dmake \ --without-ppds \ --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz " \ --with-lang="en-US zh-CN" \ --with-perl-home=/usr \ --disable-directx \ --enable-dbus \ --disable-activex \ --disable-atl \ --disable-gnome-vfs \ --enable-verbose \ --enable-dbgutil \ --with-x normally with this I get about 31MB of output. More info -- gcc 4.4.7-16 gcc-c++ support for above version libgcc-4.4.7 libstdc++-4.4.7 Now, I am getting a HUGE amount of backtraces -- sample included here (this same error repeats a million times or so it seems). So my output file is about 10x the size it usually is! .Error: File /home/kschenk/AOO_source/openoffice/trunk/main/sal/cpprt/operators_new_delete.cxx, Line 91: operator delete mismatch Backtrace: [0] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/lib/libuno_sal.so.3: osl_assertFailedLine+0x150 Backtrace: [1] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x41467 Backtrace: [2] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x41661 Backtrace: [3] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZdlPv+0x23 Backtrace: [4] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN5boost14checked_deleteIcEEvPT_+0x11 Backtrace: [5] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x38ce6 Backtrace: [6] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x371a4 Backtrace: [7] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x37216 Backtrace: [8] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x37268 Backtrace: [9] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN6Export8CopyFileERK10ByteStringS2_+0x250 Backtrace: [10] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN10HelpParser15MergeSingleFileEP7XMLFileR13MergeDataFileRK10ByteStringS4_+0x3e9 Backtrace: [11] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: _ZN10HelpParser5MergeERK10ByteStringS2_S2_bRKSt6vectorIS0_SaIS0_EER13MergeDataFileb+0x60e Backtrace: [12] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: main+0x6b0 Backtrace: [13] /lib/libc.so.6: __libc_start_main+0xe6 Backtrace: [14] /home/kschenk/AOO_source/openoffice/trunk/main/solver/420/unxlngi6/bin/helpex: ???+0x1c331 HELP! On 08/31/2015 09:12 AM, Kay Schenk wrote: > > > On 08/30/2015 11:52 PM, Damjan Jovanovic wrote: >> On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic wrote: >>> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: > On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: >> >> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: >>> Hi >>> >>> I am in the process of migrating our unit tests from cppunit to Google >>> Test. However AOO doesn't build with cppunit and hasn't been routinely >>> built with cppunit for a while, which means our unit tests are in a >>> state of neglect, and unsurprisingly, there are many failures both >>> compiling and running our unit tests. >>> >>> Ideally we should investigate why and fix the tests. But the APIs >>> being tested are complex and unfamiliar to me (eg. SVG parsing), and >>> would take very long to investigate properly. >>> >>> I could commit changes that will just get the tests to compile, then >>> fail during testing and stop the build, thus forcing others to fix >>> them quickly :-), but I don't imagine that will go down well. So I am >>> taking this approach instead: >>> >>> // FIXME: >>> #define RUN_OLD_FAILING_TESTS 0 >>> >>> #if RUN_OLD_FAILING_TESTS >>> broken_test(); >>> #endif >>> >>> Also I am making unit tests run on every build. This way at least some >>> unit tests will be run, and any future regressions to tests can be >>> caught immediately, while the broken tests can be fixed gradually. >>> >>> Everyone happy? >> >> Well pretty much. :) >> >> I've been watching your
Re: cppunit -> Google Test migration and old failing tests
On Mon, Aug 31, 2015 at 1:54 PM, Andrea Pescetti wrote: > Damjan Jovanovic wrote: >> >> I fixed several problems and am busy rebuilding. Please check if the >> latest SVN works for you. If not, please post the build log. > > > Just to say that I built the current trunk and didn't experience any > problems. Actually, even if in general I build AOO410, I had built trunk a > couple times during the weekend without any problems. > > And thank you Damjan for your work on tests! Pleasure. Just wish we had more developers, more momentum. The dev.openoffice.org IRC is so quiet, Wiki out of date and horribly organized (I find useful Wiki pages days after I actually needed them, and only by accident). You must have been extremely lucky and used --disable-unit-tests and/or didn't use a parallel build, as the build still sporadically broke for me, and I've discovered a whole new category of build-breaking bugs I may have introduced: missing dependencies which cause race conditions in parallel builds. The very latest SVN should fix all such issues I found. Also where are our buildbots? Thank you Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On 08/30/2015 11:52 PM, Damjan Jovanovic wrote: > On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic wrote: >> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: >>> >>> >>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: > > On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: >> Hi >> >> I am in the process of migrating our unit tests from cppunit to Google >> Test. However AOO doesn't build with cppunit and hasn't been routinely >> built with cppunit for a while, which means our unit tests are in a >> state of neglect, and unsurprisingly, there are many failures both >> compiling and running our unit tests. >> >> Ideally we should investigate why and fix the tests. But the APIs >> being tested are complex and unfamiliar to me (eg. SVG parsing), and >> would take very long to investigate properly. >> >> I could commit changes that will just get the tests to compile, then >> fail during testing and stop the build, thus forcing others to fix >> them quickly :-), but I don't imagine that will go down well. So I am >> taking this approach instead: >> >> // FIXME: >> #define RUN_OLD_FAILING_TESTS 0 >> >> #if RUN_OLD_FAILING_TESTS >> broken_test(); >> #endif >> >> Also I am making unit tests run on every build. This way at least some >> unit tests will be run, and any future regressions to tests can be >> caught immediately, while the broken tests can be fixed gradually. >> >> Everyone happy? > > Well pretty much. :) > > I've been watching your commits. Thank you for taking on this > challenging task. Thank you. > OK, just to be clear. It looks like you're converting the cppunit calls > to Google Test api calls. But, what you're saying is the actual use of > the Google test routines needs additional modification to work > correctly, right? Yes that's what I am doing. No, the C++ conversions are very easy (feel free to help ;-)): #include "cppunit..." => #include "gtest/gtest.h" class X : public CppUnit::TestFixture => class X : public ::testing:Test CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) CPPUNIT_FALSE(msg) => FAIL() << msg private: => protected: test methods move outside of class declaration and become TEST_F(className, methodName) instead CPPUNIT_TEST...() registrations disappear but the problem is that tests themselves are wrong no matter what the testing library. For example: basegfx::tools::importFromSvgD( aPoly, aSvg ); won't compile, as importfromSvgD() requires 4 parameters now instead of just 2 (as I explained in an earlier email, this was caused by commit 1536730 on 2013-10-29 by alg). Damjan >>> >>> A quick question on these changes. Do these require a reconfigure to >>> work correctly? I ran into a problem building with r1698208 so this is >>> why I ask. >>> >> >> I see, main/codemaker's tests don't build unless AOO is already built; >> it's probably one of those tests that needs OOO_SUBSEQUENT_TESTS. >> >> r1698208 builds for me with this patch (ie. delete the last line of >> text in main/codemaker/prj/build.lst): yes...that is what I did initially but, as you say... see below >> >> Index: main/codemaker/prj/build.lst >> === >> --- main/codemaker/prj/build.lst(revision 1700184) >> +++ main/codemaker/prj/build.lst(working copy) >> @@ -7,4 +7,3 @@ >> cmcodemaker\source\cppumakernmake-all >> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL >> cmcodemaker\source\commonjavanmake-all >> cm_java cm_inc NULL >> cmcodemaker\source\javamakernmake-all >> cm_javamaker cm_codemaker cm_java cm_inc NULL >> -cmcodemaker\test\cppumakernmake-all >> cm_cppumaker_test cm_cppumaker cm_codemaker cm_cpp cm_inc NULL >> >> However in the latest SVN I then get another build error in main/oovbaapi: >> Compiling: Globals.idl >> /tmp/idli_wyec6x: line 32: file 'com/sun/star/table/XCellRange.idl' not found >> AOO/main/solver/420/unxfbsdx/bin/idlc: preprocessing file >> /AOO/main/oovbaapi/ooo/vba/excel/Globals.idl failed >> dmake: Error code 1, while making '../../../unxfbsdx/ucr/excel.db' yep! same for me. >> >> which isn't in a module I changed. I am bisection testing between >> r1698208 and r1700184 to see what broke that. > > I fixed several problems and am busy rebuilding. Please check if the > latest SVN works for you. If not, please post the build log. > Thanks for your quick response. I'll be back in touch. -- MzK “The journey of a thousand mile
Re: cppunit -> Google Test migration and old failing tests
Damjan Jovanovic wrote: I fixed several problems and am busy rebuilding. Please check if the latest SVN works for you. If not, please post the build log. Just to say that I built the current trunk and didn't experience any problems. Actually, even if in general I build AOO410, I had built trunk a couple times during the weekend without any problems. And thank you Damjan for your work on tests! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic wrote: > On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: >> >> >> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: >>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: > Hi > > I am in the process of migrating our unit tests from cppunit to Google > Test. However AOO doesn't build with cppunit and hasn't been routinely > built with cppunit for a while, which means our unit tests are in a > state of neglect, and unsurprisingly, there are many failures both > compiling and running our unit tests. > > Ideally we should investigate why and fix the tests. But the APIs > being tested are complex and unfamiliar to me (eg. SVG parsing), and > would take very long to investigate properly. > > I could commit changes that will just get the tests to compile, then > fail during testing and stop the build, thus forcing others to fix > them quickly :-), but I don't imagine that will go down well. So I am > taking this approach instead: > > // FIXME: > #define RUN_OLD_FAILING_TESTS 0 > > #if RUN_OLD_FAILING_TESTS > broken_test(); > #endif > > Also I am making unit tests run on every build. This way at least some > unit tests will be run, and any future regressions to tests can be > caught immediately, while the broken tests can be fixed gradually. > > Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. >>> >>> Thank you. >>> OK, just to be clear. It looks like you're converting the cppunit calls to Google Test api calls. But, what you're saying is the actual use of the Google test routines needs additional modification to work correctly, right? >>> >>> Yes that's what I am doing. >>> >>> No, the C++ conversions are very easy (feel free to help ;-)): >>> #include "cppunit..." => #include "gtest/gtest.h" >>> class X : public CppUnit::TestFixture => class X : public ::testing:Test >>> CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg >>> CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) >>> CPPUNIT_FALSE(msg) => FAIL() << msg >>> private: => protected: >>> test methods move outside of class declaration and become >>> TEST_F(className, methodName) instead >>> CPPUNIT_TEST...() registrations disappear >>> >>> but the problem is that tests themselves are wrong no matter what the >>> testing library. For example: >>> basegfx::tools::importFromSvgD( aPoly, aSvg ); >>> won't compile, as importfromSvgD() requires 4 parameters now instead >>> of just 2 (as I explained in an earlier email, this was caused by >>> commit 1536730 on 2013-10-29 by alg). >>> >>> Damjan >> >> A quick question on these changes. Do these require a reconfigure to >> work correctly? I ran into a problem building with r1698208 so this is >> why I ask. >> > > I see, main/codemaker's tests don't build unless AOO is already built; > it's probably one of those tests that needs OOO_SUBSEQUENT_TESTS. > > r1698208 builds for me with this patch (ie. delete the last line of > text in main/codemaker/prj/build.lst): > > Index: main/codemaker/prj/build.lst > === > --- main/codemaker/prj/build.lst(revision 1700184) > +++ main/codemaker/prj/build.lst(working copy) > @@ -7,4 +7,3 @@ > cmcodemaker\source\cppumakernmake-all > cm_cppumaker cm_codemaker cm_cpp cm_inc NULL > cmcodemaker\source\commonjavanmake-all > cm_java cm_inc NULL > cmcodemaker\source\javamakernmake-all > cm_javamaker cm_codemaker cm_java cm_inc NULL > -cmcodemaker\test\cppumakernmake-all > cm_cppumaker_test cm_cppumaker cm_codemaker cm_cpp cm_inc NULL > > However in the latest SVN I then get another build error in main/oovbaapi: > Compiling: Globals.idl > /tmp/idli_wyec6x: line 32: file 'com/sun/star/table/XCellRange.idl' not found > AOO/main/solver/420/unxfbsdx/bin/idlc: preprocessing file > /AOO/main/oovbaapi/ooo/vba/excel/Globals.idl failed > dmake: Error code 1, while making '../../../unxfbsdx/ucr/excel.db' > > which isn't in a module I changed. I am bisection testing between > r1698208 and r1700184 to see what broke that. I fixed several problems and am busy rebuilding. Please check if the latest SVN works for you. If not, please post the build log. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: > > > On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: >> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: >>> >>> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? >>> >>> Well pretty much. :) >>> >>> I've been watching your commits. Thank you for taking on this >>> challenging task. >> >> Thank you. >> >>> OK, just to be clear. It looks like you're converting the cppunit calls >>> to Google Test api calls. But, what you're saying is the actual use of >>> the Google test routines needs additional modification to work >>> correctly, right? >> >> Yes that's what I am doing. >> >> No, the C++ conversions are very easy (feel free to help ;-)): >> #include "cppunit..." => #include "gtest/gtest.h" >> class X : public CppUnit::TestFixture => class X : public ::testing:Test >> CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg >> CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) >> CPPUNIT_FALSE(msg) => FAIL() << msg >> private: => protected: >> test methods move outside of class declaration and become >> TEST_F(className, methodName) instead >> CPPUNIT_TEST...() registrations disappear >> >> but the problem is that tests themselves are wrong no matter what the >> testing library. For example: >> basegfx::tools::importFromSvgD( aPoly, aSvg ); >> won't compile, as importfromSvgD() requires 4 parameters now instead >> of just 2 (as I explained in an earlier email, this was caused by >> commit 1536730 on 2013-10-29 by alg). >> >> Damjan > > A quick question on these changes. Do these require a reconfigure to > work correctly? I ran into a problem building with r1698208 so this is > why I ask. > I see, main/codemaker's tests don't build unless AOO is already built; it's probably one of those tests that needs OOO_SUBSEQUENT_TESTS. r1698208 builds for me with this patch (ie. delete the last line of text in main/codemaker/prj/build.lst): Index: main/codemaker/prj/build.lst === --- main/codemaker/prj/build.lst(revision 1700184) +++ main/codemaker/prj/build.lst(working copy) @@ -7,4 +7,3 @@ cmcodemaker\source\cppumakernmake-all cm_cppumaker cm_codemaker cm_cpp cm_inc NULL cmcodemaker\source\commonjavanmake-all cm_java cm_inc NULL cmcodemaker\source\javamakernmake-all cm_javamaker cm_codemaker cm_java cm_inc NULL -cmcodemaker\test\cppumakernmake-all cm_cppumaker_test cm_cppumaker cm_codemaker cm_cpp cm_inc NULL However in the latest SVN I then get another build error in main/oovbaapi: Compiling: Globals.idl /tmp/idli_wyec6x: line 32: file 'com/sun/star/table/XCellRange.idl' not found AOO/main/solver/420/unxfbsdx/bin/idlc: preprocessing file /AOO/main/oovbaapi/ooo/vba/excel/Globals.idl failed dmake: Error code 1, while making '../../../unxfbsdx/ucr/excel.db' which isn't in a module I changed. I am bisection testing between r1698208 and r1700184 to see what broke that. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
No they shouldn't. It's possible something broke. Do you have a log of the build? On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk wrote: > > > On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: >> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: >>> >>> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? >>> >>> Well pretty much. :) >>> >>> I've been watching your commits. Thank you for taking on this >>> challenging task. >> >> Thank you. >> >>> OK, just to be clear. It looks like you're converting the cppunit calls >>> to Google Test api calls. But, what you're saying is the actual use of >>> the Google test routines needs additional modification to work >>> correctly, right? >> >> Yes that's what I am doing. >> >> No, the C++ conversions are very easy (feel free to help ;-)): >> #include "cppunit..." => #include "gtest/gtest.h" >> class X : public CppUnit::TestFixture => class X : public ::testing:Test >> CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg >> CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) >> CPPUNIT_FALSE(msg) => FAIL() << msg >> private: => protected: >> test methods move outside of class declaration and become >> TEST_F(className, methodName) instead >> CPPUNIT_TEST...() registrations disappear >> >> but the problem is that tests themselves are wrong no matter what the >> testing library. For example: >> basegfx::tools::importFromSvgD( aPoly, aSvg ); >> won't compile, as importfromSvgD() requires 4 parameters now instead >> of just 2 (as I explained in an earlier email, this was caused by >> commit 1536730 on 2013-10-29 by alg). >> >> Damjan > > A quick question on these changes. Do these require a reconfigure to > work correctly? I ran into a problem building with r1698208 so this is > why I ask. > > > -- > > MzK > > “The journey of a thousand miles begins > with a single step.” > --Lao Tzu > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: > On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: >> >> On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: >>> Hi >>> >>> I am in the process of migrating our unit tests from cppunit to Google >>> Test. However AOO doesn't build with cppunit and hasn't been routinely >>> built with cppunit for a while, which means our unit tests are in a >>> state of neglect, and unsurprisingly, there are many failures both >>> compiling and running our unit tests. >>> >>> Ideally we should investigate why and fix the tests. But the APIs >>> being tested are complex and unfamiliar to me (eg. SVG parsing), and >>> would take very long to investigate properly. >>> >>> I could commit changes that will just get the tests to compile, then >>> fail during testing and stop the build, thus forcing others to fix >>> them quickly :-), but I don't imagine that will go down well. So I am >>> taking this approach instead: >>> >>> // FIXME: >>> #define RUN_OLD_FAILING_TESTS 0 >>> >>> #if RUN_OLD_FAILING_TESTS >>> broken_test(); >>> #endif >>> >>> Also I am making unit tests run on every build. This way at least some >>> unit tests will be run, and any future regressions to tests can be >>> caught immediately, while the broken tests can be fixed gradually. >>> >>> Everyone happy? >> >> Well pretty much. :) >> >> I've been watching your commits. Thank you for taking on this >> challenging task. > > Thank you. > >> OK, just to be clear. It looks like you're converting the cppunit calls >> to Google Test api calls. But, what you're saying is the actual use of >> the Google test routines needs additional modification to work >> correctly, right? > > Yes that's what I am doing. > > No, the C++ conversions are very easy (feel free to help ;-)): > #include "cppunit..." => #include "gtest/gtest.h" > class X : public CppUnit::TestFixture => class X : public ::testing:Test > CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg > CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) > CPPUNIT_FALSE(msg) => FAIL() << msg > private: => protected: > test methods move outside of class declaration and become > TEST_F(className, methodName) instead > CPPUNIT_TEST...() registrations disappear > > but the problem is that tests themselves are wrong no matter what the > testing library. For example: > basegfx::tools::importFromSvgD( aPoly, aSvg ); > won't compile, as importfromSvgD() requires 4 parameters now instead > of just 2 (as I explained in an earlier email, this was caused by > commit 1536730 on 2013-10-29 by alg). > > Damjan A quick question on these changes. Do these require a reconfigure to work correctly? I ran into a problem building with r1698208 so this is why I ask. -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Am 08/28/2015 06:07 PM, schrieb Kay Schenk: On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. also from my side a big thank you for your migration efforts. I'm not a developer, so I don't know how much work it is. But it's good to see that you want to bring these area to a more modern base. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk wrote: > > On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: >> Hi >> >> I am in the process of migrating our unit tests from cppunit to Google >> Test. However AOO doesn't build with cppunit and hasn't been routinely >> built with cppunit for a while, which means our unit tests are in a >> state of neglect, and unsurprisingly, there are many failures both >> compiling and running our unit tests. >> >> Ideally we should investigate why and fix the tests. But the APIs >> being tested are complex and unfamiliar to me (eg. SVG parsing), and >> would take very long to investigate properly. >> >> I could commit changes that will just get the tests to compile, then >> fail during testing and stop the build, thus forcing others to fix >> them quickly :-), but I don't imagine that will go down well. So I am >> taking this approach instead: >> >> // FIXME: >> #define RUN_OLD_FAILING_TESTS 0 >> >> #if RUN_OLD_FAILING_TESTS >> broken_test(); >> #endif >> >> Also I am making unit tests run on every build. This way at least some >> unit tests will be run, and any future regressions to tests can be >> caught immediately, while the broken tests can be fixed gradually. >> >> Everyone happy? > > Well pretty much. :) > > I've been watching your commits. Thank you for taking on this > challenging task. Thank you. > OK, just to be clear. It looks like you're converting the cppunit calls > to Google Test api calls. But, what you're saying is the actual use of > the Google test routines needs additional modification to work > correctly, right? Yes that's what I am doing. No, the C++ conversions are very easy (feel free to help ;-)): #include "cppunit..." => #include "gtest/gtest.h" class X : public CppUnit::TestFixture => class X : public ::testing:Test CPPUNIT_ASSERT_MESSAGE(msg, condition) => ASSERT_TRUE(condition) << msg CPPUNIT_ASSERT_EQUAL(c1, c2)=> ASSERT_EQ(c1, c2) CPPUNIT_FALSE(msg) => FAIL() << msg private: => protected: test methods move outside of class declaration and become TEST_F(className, methodName) instead CPPUNIT_TEST...() registrations disappear but the problem is that tests themselves are wrong no matter what the testing library. For example: basegfx::tools::importFromSvgD( aPoly, aSvg ); won't compile, as importfromSvgD() requires 4 parameters now instead of just 2 (as I explained in an earlier email, this was caused by commit 1536730 on 2013-10-29 by alg). Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: > Hi > > I am in the process of migrating our unit tests from cppunit to Google > Test. However AOO doesn't build with cppunit and hasn't been routinely > built with cppunit for a while, which means our unit tests are in a > state of neglect, and unsurprisingly, there are many failures both > compiling and running our unit tests. > > Ideally we should investigate why and fix the tests. But the APIs > being tested are complex and unfamiliar to me (eg. SVG parsing), and > would take very long to investigate properly. > > I could commit changes that will just get the tests to compile, then > fail during testing and stop the build, thus forcing others to fix > them quickly :-), but I don't imagine that will go down well. So I am > taking this approach instead: > > // FIXME: > #define RUN_OLD_FAILING_TESTS 0 > > #if RUN_OLD_FAILING_TESTS > broken_test(); > #endif > > Also I am making unit tests run on every build. This way at least some > unit tests will be run, and any future regressions to tests can be > caught immediately, while the broken tests can be fixed gradually. > > Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. OK, just to be clear. It looks like you're converting the cppunit calls to Google Test api calls. But, what you're saying is the actual use of the Google test routines needs additional modification to work correctly, right? > > Regards > Damjan > -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
+1 Thank you for working on this. Having working unit tests is key for future development! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
cppunit -> Google Test migration and old failing tests
Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? Regards Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org