Provision of enabling tests for frameworks

[Sharaf Zaman]

Volker Krause <vkrause at kde.org> writes:

> On Donnerstag, 12. Januar 2023 20:49:13 CET Sharaf Zaman wrote:
>> Aleix Pol <aleixpol at kde.org> writes:
>> > On Thu, Jan 12, 2023 at 7:22 PM Sharaf Zaman <shzam at sdf.org> wrote:
>> >> Volker Krause <vkrause at kde.org> writes:
>> >> > On Dienstag, 10. Januar 2023 19:10:24 CET Sharaf Zaman wrote:
>> >> >> Today I encountered a bug with KConfig [1], which surfaced because of
>> >> >> the
>> >> >> quirks of QSaveFile and Android. Even though these bugs are trivial
>> >> >> [2],
>> >> >> but having them in code is bad (especially since, saving files,
>> >> >> configs can
>> >> >> be serious if not done properly).
>> >> >>
>> >> >> So, I’d like to ask, is there somebody who is working on getting unit
>> >> >> tests
>> >> >> etc to work on Android for kde-frameworks? If not, do you think it
>> >> >> would be
>> >> >> a good idea to think about it right now? Given more and more KDE apps
>> >> >> are
>> >> >> getting on mobile platform.
>> >> >
>> >> > I absolutely would like to have Android unit tests! Having fixed some
>> >> > of those file I/O issue in Qt and KDE code myself I feel your pain
>> >> > there.
>> >> >
>> >> > As Aleix said, the main challenge is figuring out how to do that. It
>> >> > might help if we do CI builds for x86 rather than/in addition to ARM?
>> >> > Craft can do that, even if the current CI image might not contain that
>> >> > configuration. That might be easier to execute in the Android emulator
>> >> > then, which presumably is how we would run tests on the CI?
>> >> >
>> >> > Regards,
>> >> > Volker
>> >> >
>> >> >
>> >> > It might help if we do CI builds for x86 rather than/in addition to
>> >> > ARM?
>> >>
>> >> Yes, I think it will be wise to have x86 image since the metrics will be
>> >> more realistic than emulation of ARM on x86.
>> >>
>> >> > Craft can do that, even if the current CI image might not contain that>
>> >> > configuration.
>> >>
>> >> You mean Craft can build x86 images or it can build _tests_? (which will
>> >> make me jump to try it :) )
>> >
>> > Building tests is easy, running them is the hard part as they’re weird
>> > .so files.
>> > Would we have to turn them all into apks? If that’s what it needs
>> > (which wouldn’t be entirely weird), we will need to do some work on
>> > it.
>
> Building even already happens as part of the existing CI runs.
>
>> > Would we have to turn them all into apks? If that’s what it needs
>> > (which wouldn’t be entirely weird), we will need to do some work on
>> > it.
>>
>> Good question. Previously in past I’ve run simple binaries straight from
>> /data/local/tmp using adb. Maybe it won’t be necessary to build APK for all
>> but a few tests that depend on say libQt5Gui.so?
>
> If we can get away without APKs, that would be massively faster I guess. The
> emulator is essentially a rooted device, so we do have more flexibility there.
>
> Besides the test itself we would also need to push all necessary libraries and
> data files though. Not sure if that’s still sufficiently similar to the APK
> scenario then, correctly finding resources/data files is another common Android
> problem after all.
>

Yes, even if we have to push resources on each run it will still be massively
faster because Android won’t have to analyze/compress/decompress them. If I
remember correctly one of the presentations from Qt company mentioned that
buildling is the most time intsenive thing about testing on Andorid. So if we
can hack our way, it may be a great improvement to developer experience :)

> Regards,
> Volker

I did a little bit of hacking and it *is* possible to run Qt binaries without
having to convert them to .so and then dlopen them. But I found that there may
be quirks we’d need to deal with, one being, QtCore trying to attach itself to a
javaVM even when if we run process without the help of the platform plugin.