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
