Re: Accessing main window menus during C++ test run

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

 



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





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

  Powered by Linux