Accessing main window menus during C++ test run

[Colomban Wendling]

Hello Xisco, thanks for your message.

Unfortunately this blog post, while instructive, is not really helpful 
as the accessibility approach is mentioned as having been discarded 
mostly because the accessibility implementation in LO was deemed not 
robust enough, so not a reliable basis for designing a new framework on top.

Unfortunately here I'm actually *trying* to exercise the accessibility 
implementation in the hope it'll help with improving it, so I cannot 
just ignore it :)

Thanks anyway, and any more knowledge would still be highly appreciated!

Regards,
Colomban

Le 26/05/2022 à 10:11, Xisco Fauli a écrit :
> Hello Colomban,
> 
> The UItest framework [1] uses UNO commands to interact with the UI. 
> However, Markus also evaluated the accessibility approach when he 
> implemented it. You can read more in 
> https://mmohrhard.wordpress.com/2016/09/07/ui-testing-in-libreoffice/. I 
> hope it helps.
> 
> Cheers
> 
> [1] https://wiki.documentfoundation.org/Development/UITests
> 
> On 25/5/22 19:16, Colomban Wendling wrote:
>> Hello everybody,
>>
>> I'm trying to interact with the UI in a CppUnit test, or more 
>> specifically with the accessible objects representing it, as part of 
>> the CppUnit accessibility unit tests project I'm working on.
>>
>> I have no trouble reaching the top window or document, but most UI 
>> around the document seem empty, and specifically in the current area 
>> I'm pursuing right now: the menus.  I can get a hold of the menubar, 
>> but it has no children whatsoever.  Same goes for e.g. the statusbar.
>>
>> I even tried hacking around VCL's Menu class to see whether it was the
>> accessible objects I was lacking, but no, barely any menu items are
>> constructed for my test runs, whereas a whole lot of them are during a 
>> normal run, as expected.
>>
>> What I do to create my test windows don't seem too odd to me: I'm 
>> calling XDesktop2::loadComponentFromURL(), where the instance comes 
>> from 
>> frame::Desktop::create(test::BootstrapFixture::mxComponentContext) -- 
>> same goes trying to use UnoApiTest::mxDesktop::loadComponentFromURL().
>> My naive expectation was that I'd get a full-featured window with the
>> corresponding document, but apparently I only get a mock or subset of 
>> the actual UI.
>>
>> So, is there a way to get a full-featured UI in a test, and how? Or to 
>> load specific parts of the UI on demand, so to have the same behavior 
>> a normal run would have?
>>
>> Currently I'm working with Writer, but any component would be fine for 
>> now, and ideally I'd have a solution for all of them; but any one 
>> would be a good enough start :)
>>
>> BTW I know I could perform actions sending UNO commands, but here I'm 
>> really more interested in the UI elements behavior and accessibility 
>> than the commands they trigger, so that's not a solution.
>>
>> I'd be very glad to get any pointers that could help, thanks!
>>
>> Regards,
>> Colomban Wendling
>