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