Testing - Embedded QML CI tests

Why?

Cause

• As the feature depends on several APIs, tools and components, we would like to tests their functionality all together in an integration test in COIN.
• Test everything together, except QtTAS, from Qt Quick for Android
• In COIN we can catch QML vs JAVA communication breaks per committed patch

Customer

-

Cruft

• COIN/CI usually have had unit tests
•  

What?

Definition

Android application with Java and QML and integration

QtQuickView is supposed to be used in native Java/Kotlin Android applications. There are several components & APIs other than QtQuickView itself that are involved in the feature.

• APIS:
  • QtQuickView (does not have CI unit tests)
  • QtSignalListener  (does not have CI unit tests)
  • QtQmlStatus & QtQmlStatusListener  (does not have CI unit tests)
  • QtQuickViewContent (through generated code)  (does not have CI unit tests)
  • QtAbstractItemModel & QtAbstractListModel (has CI unit tests)
• Components
  • .AAR target
  • QtQuickViewContent based code generator (strong typing)
  • Qt Gradle Plugin (using it)

Note: A minimal integration test application can exclude abstract model APIs to test them separately.

Demarcation

• Not an integration test i.e. each API separately
• Not a release test (RT), instead testing each commit
• Not IDE testing
• Qt related testing

Dependencies

How?

1. Host Android Application: By excluding Qt specific binaries and resources from an APK target, and using non-QtActivity based Android Activity we will be able to create a "native-like" Android application that hosts QtQuickView and related APIs. For this purpose, we can
   • Use QT_ANDROID_NO_DEPLOY_QT_LIBS Cmake variable to exclude .so files from being deployed to the APK. 
   • Use a custom build.gradle file that does NOT include Qt specific resources and jars.
   • Use a custom AndroidManifest.xml that sets the custom Activity as the main activity (instead of the QtActivity based one)
   • The custom build.gradle file will use Qt Gradle Plugin to link to the QML application.
2. QML Test Application: As all Qt libraries has been excluded from the "host app" that mimics the native Android application, all Qt specific binaries including QtTest should be a part of the QML application. The target will an AAR library that will be included and used by the host application. Qt Gradle Plugin in the build.gradle of the host application will generate and include the  AAR.

Note: The main Activity of the host application can potentially have JNI native methods. The QML application should register native implementation of those methods with JNI.

Note: The host application adds QtQuickView to a layout of the activity. That is where the test starts because adding QtQuickView also loads the Qt binaries, hence the entry point.

Note: As the QtQuickView is supposed to instantiate QQuickView, a typical quick test project with  QUICK_TEST_MAIN won't work in our case. The feasibility of having a custom entry point should be verified.

Note: Alternatively we can stick to using QTEST_MAIN and add a test to set/verify QML properties through a reference to the root object of the quick view, instead of writing a qml test.