CppunitTest: different results depending on execution command

[Michael Stahl]

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 at libreoffice.org> 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.