On 08/30/2015 11:52 PM, Damjan Jovanovic wrote:
> On Mon, Aug 31, 2015 at 5:54 AM, Damjan Jovanovic <dam...@apache.org> wrote:
>> 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):
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
