Need help in getting started with writing the integration test

[Tobias Deiminger]

Am 06.06.2018 23:17 schrieb Albert Astals Cid:
> El dimecres, 6 de juny de 2018, a les 15:43:01 CEST, Dileep Sankhla va
> escriure:
>> PageViewAnnotator pageviewannotator(part.m_pageView, part.m_document);
>> pageviewannotator.setEnabled( true );
> 
> Why don't you just call PageView::slotToggleAnnotator ?
> 
>> 
>> But on make, I'm getting linking error as the undefined reference to
>> PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)
>> 
>> How to resolve this and check for the typewriter tool button in the 
>> toolbar?
> 
> PageViewAnnotator is not an exported class so you can't call functions 
> on it
> because those functions are not part of the library. You'll have the 
> same
> "problem" with PageView::slotToggleAnnotator.

Thanks for your explanation! I'm adding a few technical bits. If you 
want to see which symbols from an ELF library like okularpart.so can 
used by linking programs (like parttest), you can check for "g" (Global 
Symbol) flags with objdump. Every class that was defined with "class 
OKULARPART_EXPORT" should have become global.

$ objdump -tC okularpart.so | grep PageViewAnnotator::PageViewAnnotator
000000000011a10e l     F .text  00000000000000db              
PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)
000000000011a10e l     F .text  00000000000000db              
PageViewAnnotator::PageViewAnnotator(PageView*, Okular::Document*)

Here the flag in the second column is a "l", which stands for "Local 
symbol". So PageViewAnnotator::PageViewAnnotator is only visible from 
within okularpart.so, but not for another binary that wants to link to 
okularpart.so (like parttest). See also 
https://gcc.gnu.org/wiki/Visibility. Not that for other binary formats 
and compilers it's a bit different.

> In this case it can be workarounded since it's a slot and you can use 
> qobject
> magic to call it. See the QMetaObject::invokeMethod calls in parttest
> 
> Cheers,
>   Albert
> 
>> 
>> 
>> 
>> 
>> On Wed, Jun 6, 2018 at 3:08 PM, Dileep Sankhla 
>> <sankhla.dileep96 at gmail.com>
>> 
>> wrote:
>> > I have just begun to write the test for typewriter annotation tool and my
>> > first test case is "checking if the annotation toolbar has the typewriter
>> > tool button in it?"

The button check is maybe not the most important test case wrt 
functionality. But it's a very good one to learn about testing. So go on 
with it :)

>> > Till now I have been succeeded in opening the document data/file1.pdf with
>> > the current page as 0 by using the object of Okular::Part and now I'm not
>> > getting the way of showing the annotation toolbar and how will I check for
>> > the typewriter tool in it?

If you only want to check the toolbar and its buttons, don't load a 
document at all. Toolbar and buttons are instantiated independent from 
having a document open. You want to keep out not needed functionality, 
to make a potential failed test more spot on.

>> > Do I need to simulate <F6> keypress for showing the annotation toolbar and

You could, but Alberts suggestion of using PageView::slotToggleAnnotator 
is better, because it's a more direct way to achieve what you want to 
achieve.

>> > if yes, then how will I check for the specific tool in it?

You could probably use QToolBar* toolbar = 
part.m_pageView->findChild<QToolBar*>(), and then use 
QToolBar::widgetForAction to look for the button.
Or you do a subsequent toolbar->findChildren<QToolButton*>(), to get a 
list of the inner buttons.

Finally you can access the icon with QAbstractButton::icon().

Cheers
Tobias

>> > Need help.
>> >
>> > Thanks and Regards
>> > Dileep
>> >
>> >
>> >
>> >
>> > On Mon, Jun 4, 2018 at 1:19 AM, Tobias Deiminger <haxtibal at posteo.de>
>> >
>> > wrote:
>> >> Am 03.06.2018 21:39 schrieb Tobias Deiminger:
>> >>> Am 03.06.2018 08:05 schrieb Dileep Sankhla:
>> >> Ups, I misread the question
>> >>
>> >>> What will I compare here?
>> >>
>> >> as "what will compare here?"
>> >>
>> >> GUI tests compare with autotests/parttest.cpp.
>> >>
>> >>> Core tests potentially compare with autotests/*annot*.cpp
>> >>> Afaikt there are no tests yet that check painting results pixel wise.
>> >>
>> >> New answer: You compare actual outcome with expected outcome. What actual
>> >> outcome and expected outcome means depends on your test case. You have to
>> >> define it.
>> >>
>> >> Tobias