You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2015/08/28 06:05:10 UTC
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Damjan Jovanovic <da...@gmail.com>.
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 <ka...@gmail.com> wrote:
>
>
> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Kay Schenk <ka...@gmail.com>.
[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 <da...@apache.org> wrote:
>>>> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <ka...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>>>>>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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 @@
>>>> cm codemaker\source\cppumaker nmake - all
>>>> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL
>>>> cm codemaker\source\commonjava nmake - all
>>>> cm_java cm_inc NULL
>>>> cm codemaker\source\javamaker nmake - all
>>>> cm_javamaker cm_codemaker cm_java cm_inc NULL
>>>> -cm codemaker\test\cppumaker nmake - 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 miles begins
with a single step.”
--Lao Tzu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Kay Schenk <ka...@gmail.com>.
[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 <da...@apache.org> wrote:
>>> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <ka...@gmail.com> wrote:
>>>>
>>>>
>>>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>>>>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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 @@
>>> cm codemaker\source\cppumaker nmake - all
>>> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL
>>> cm codemaker\source\commonjava nmake - all
>>> cm_java cm_inc NULL
>>> cm codemaker\source\javamaker nmake - all
>>> cm_javamaker cm_codemaker cm_java cm_inc NULL
>>> -cm codemaker\test\cppumaker nmake - 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 miles begins
with a single step.”
--Lao Tzu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Kay Schenk <ka...@gmail.com>.
On 08/30/2015 11:52 PM, Damjan Jovanovic wrote:
> On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic <da...@apache.org> wrote:
>> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <ka...@gmail.com> wrote:
>>>
>>>
>>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>>>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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 @@
>> cm codemaker\source\cppumaker nmake - all
>> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL
>> cm codemaker\source\commonjava nmake - all
>> cm_java cm_inc NULL
>> cm codemaker\source\javamaker nmake - all
>> cm_javamaker cm_codemaker cm_java cm_inc NULL
>> -cm codemaker\test\cppumaker nmake - 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 miles begins
with a single step.”
--Lao Tzu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Damjan Jovanovic <da...@apache.org>.
On Mon, Aug 31, 2015 at 1:54 PM, Andrea Pescetti <pe...@apache.org> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Andrea Pescetti <pe...@apache.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Damjan Jovanovic <da...@apache.org>.
On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic <da...@apache.org> wrote:
> On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <ka...@gmail.com> wrote:
>>
>>
>> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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 @@
> cm codemaker\source\cppumaker nmake - all
> cm_cppumaker cm_codemaker cm_cpp cm_inc NULL
> cm codemaker\source\commonjava nmake - all
> cm_java cm_inc NULL
> cm codemaker\source\javamaker nmake - all
> cm_javamaker cm_codemaker cm_java cm_inc NULL
> -cm codemaker\test\cppumaker nmake - 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Damjan Jovanovic <da...@apache.org>.
On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>
> On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
>> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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 @@
cm codemaker\source\cppumaker nmake - all
cm_cppumaker cm_codemaker cm_cpp cm_inc NULL
cm codemaker\source\commonjava nmake - all
cm_java cm_inc NULL
cm codemaker\source\javamaker nmake - all
cm_javamaker cm_codemaker cm_java cm_inc NULL
-cm codemaker\test\cppumaker nmake - 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Kay Schenk <ka...@gmail.com>.
On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
> On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Damjan Jovanovic <da...@apache.org>.
On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk <ka...@gmail.com> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Marcus <ma...@wtnet.de>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: cppunit -> Google Test migration and old failing tests
Posted by Kay Schenk <ka...@gmail.com>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org