-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[office] Add regression tests for PDFDocumentPage. #101
base: master
Are you sure you want to change the base?
Conversation
Has been rebased on master after scrolling changes for search match. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the pixels and positions in the tests scare me, how easily those will get broken or not work on different device. Can have but just hope there won't be too much maintenance burden on them.
Some minor comments but can merge even if tests don't cover everything etc, just as long the running code side is clean end tests provide some use.
default: | ||
if (d->document->isLocked()) | ||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default case leaks memory? Should warn? Could also note code changes in commit message and why they were done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this is dirty fallback solution for the following issue:
- load a valid PDF file and render it;
- load a locked PDF file with the same PdfDocument instance (by calling setDocument());
- having a race condition in PdfCanvas that may call updatePaintNode() from the rendering thread before the page count is reset to zero by line 758.
In that situation you may have some rendering job in the queue before the document is unlocked, which segfault later in pdfjob.cpp#61 when calling page() on a non-existing one.
What do you think ? Is it better to try to cure this race condition, that doesn't happen in practice because we're not reusing the same PdfDocument instance each time ; or should I add a comment here mentioning the reason ?
Besides, writing this, I notice that I should convert the Q_ASSERT() I've added in pdfjob.cpp#61 as a return statement for the same race condition reason with a document smaller than the previous one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For things that cannot happen in normal operation of the application I wouldn't mind if there are small workarounds avoiding wrong behavior in testing. However, those should be clearly marked with comments, maybe even doing qWarning(), so it's possible to catch the problem if application behavior ever changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've added a comment before the test. I've also added some qWarning() in pdfjob.cpp to signal something unusual happening (and avoid segfaults also).
rpm/sailfish-office.spec
Outdated
%package tests | ||
Summary: Unitary tests for %{name} | ||
License: GPLv2 | ||
Group: System/Base |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think license gets inherited. Not sure if System/Base is better, could just skip that as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, removed.
property alias document: pdfDocument | ||
property alias placeHolder: placeHolderLoader | ||
property alias toolbar: toolbar | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commonly not fond of adding very much code used only for testing, but can have some. Just thinking it could be marked for such usage so it's not accidentally removed as cleanup. Maybe could also have all testability properties of the file grouped together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I try to tune the tests so added accessors may have a sense from a public API point of view, like exposing the toolbar item so any external user of the PDFDocumentPage item may control better the toolbar behaviour for their own needs.
Well, for the moment, I've simply added a comment on every added accessors…
I have the same concern, as I said in the introduction. I've tried to use reduced page coordinates as often as possible. I may have left mistakes also… The actual coordinates used for mouse inputs should currently all be in reduce coordinates to ensure that it doesn't depend on screen resolution… The tricky parts are when checking that the screen has scrolled of the appropriated amount to ensure that a reduce coordinate point is visible or in a corner… Maybe readability (and maintainance burden) will be improved by writing check functions specific to our case (i.e. check actual flickable position from reduced coordinates and constraints), something like:
I'll try to polish the tests in that direction during the week. |
d8aa799
to
537cbac
Compare
I've factorised some of the code repeated here and there in the test to press at given page coordinates. I've also checked that all coordinates are given in reduced page coordinates. I think the tests should be valid on other screen resolutions also. |
Tried running on jolla 1, which worked fine, and tablet, which didn't fully:
Think some emulated clicks don't find their targets. Option would be to trigger click signal manually, but that would require exposing more toolbar internals. |
Thank you for testing this on different screen resolutions. |
ac78109
to
e82819a
Compare
Rebased on master, works on JollaC, will test on Tablet later (@chriadam). |
This is quite WIP, but worth to share I think. Using the qmltestrunner and the methodology that was described in the document @pvuorela sent me, I've added some regression tests to the PDF renderer page.
Of course, it's not testing extensively all possibilities, but it already ensures that:
It's not testing yet the selection capability and the annotation ones.
It must be run with the device display on but the device can be either in portrait or landscape orientation. I tried to make the position checks resolution independant but I guess it will require some adjustments for other device than JollaC I tested it on.
Finally, I needed to add some accessors in the QML parts and I added a correction in pdfrenderthread.cpp to avoid a race condition when changing documents without changing PDFDocumentPage QML object. Oh, I forgot, I modified also the scrollTo() and contentAt() functions for the latter not to constraint the calculated point into the view, and delegate this constraint to the scroll routine instead.
Is it going in the right direction ? Should tests be written in a different way ? What do you think ?