Re: CppunitTest: different results depending on execution command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27.07.20 17:54, Xisco Fauli wrote:
Hello Miklos,

On 27/7/20 8:46, Miklos Vajna wrote:
Hi Xisco,

On Fri, Jul 24, 2020 at 07:51:30PM +0200, Xisco Fauli <xiscofauli@xxxxxxxxxxxxxxx> wrote:
as I mentioned yesterday in the ESC meeting, i'm working on a unittest
that is passing for me locally but it fails in Jenkins. The patch is
here: https://gerrit.libreoffice.org/c/core/+/99214

it turned out it passes when executed with 'make CppunitTest_sw_uiwriter
CPPUNIT_TEST_NAME="testTdf132911::TestBody"' but fails when executed
with 'make CppunitTest_sw_uiwriter'.

Any idea why it passes when the test is executed alone and why it fails
when not ?
Most probably one of the tests violate that invariant that none of the
test cases in a suite should alter the global state. You could try to
disable the tests from the suite, i.e. binary search what test causes
the problem. Hopefully you can find a single 2nd test that makes your
new test fail, and then that's easier to investigate that the whole
sw_uiwriter suite, which has 300+ test cases.

After disabling some tests here and there, I found
SwUiWriterTest::testRedlineViewAuthor is the one affecting the execution
of the new test.

I'm not sure why it's happening yet but I do believe it has to do with
the view being set in
https://opengrok.libreoffice.org/xref/core/sw/qa/extras/uiwriter/uiwriter.cxx?r=99d4bf94#5477

I tried to add the following like at the end of the unittest but it
didn't work:

pDocShell->GetViewShell()->GetViewFrame()->GetDispatcher()->Execute(SID_CLOSEWIN,
SfxCallMode::SYNCHRON);

( similar to destroyView in lokhelper <
https://opengrok.libreoffice.org/xref/core/sfx2/source/view/lokhelper.cxx?r=2f72fa98#93
)

Any idea what is happening and how to solve it? Otherwise I might go
with your second solution and put the test somewhere else.

the problem is that it sets a different redline author; this causes different paths to be taken in AppendRedline() with checks like pRedl->IsOwnRedline(*pNewRedl).

btw i think i'll revert the fix for that bug because i accidentally wrote a different fix for it last week (and now i know why that one only worked on my master build, because guess what, it has a user-name set for some different bug so the redline author name isn't "Unknown Author"...), and today i found out why the 2 commits don't like each other.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux