Re: cppunit -> Google Test migration and old failing tests

2015-08-31 Thread Damjan Jovanovic
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

2015-08-31 Thread Kay Schenk


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.


-- 

Re: cppunit -> Google Test migration and old failing tests

2015-08-31 Thread Damjan Jovanovic
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

2015-08-31 Thread Kay Schenk
[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?
>>

Re: cppunit -> Google Test migration and old failing tests

2015-08-31 Thread Kay Schenk
[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 

Re: cppunit -> Google Test migration and old failing tests

2015-08-31 Thread Andrea Pescetti

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

2015-08-30 Thread Kay Schenk


On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
 On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: cppunit - Google Test migration and old failing tests

2015-08-30 Thread Damjan Jovanovic
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 kay.sch...@gmail.com wrote:


 On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
 On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@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-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

2015-08-30 Thread Damjan Jovanovic
On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk kay.sch...@gmail.com wrote:


 On 08/29/2015 12:37 AM, Damjan Jovanovic wrote:
 On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@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 @@
 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

2015-08-29 Thread Marcus

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

2015-08-29 Thread Damjan Jovanovic
On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: cppunit - Google Test migration and old failing tests

2015-08-28 Thread Pedro Giffuni

+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



Re: cppunit - Google Test migration and old failing tests

2015-08-28 Thread 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.

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