Host-based unit tests #17
Conversation
divergentdave
force-pushed
the
david/desktop-library
branch
from
ffb22ff to
ba8dae7
Compare
divergentdave
changed the title
There was a problem hiding this comment.
What are these .pro files? Since they're either empty or completely commented out, can we omit them?
There was a problem hiding this comment.
They're Proguard files, introduced by the Android Studio new module wizard. Proguard is responsible for minifying/obfuscating class files, so these files govern exclusions of classes, methods, fields, etc. that need to have their names preserved if they are used by reflection, etc. The files are directly referenced by proguardFiles() and consumerProguardFiles() directives in the build system. The AAR includes a proguard.txt file that is probably merged from consumerProguardFiles() inputs. I'm inclined to keep them, since they're a normal part of an Android project.
There was a problem hiding this comment.
Fair enough, I don't have a good enough argument to push for removing them.
This repeats the existing client smoke tests on the host, in addition to running them in an emulator. This closes #3. I moved some of the common setup code to a new library module, so I could reuse it via intra-project dependencies. I also had to provide a mock for
android.util.Base64, since it's not available on the host. It was easy to polyfill usingjava.util.Base64.Using the native library in host unit tests is enabled by adding a desktop target to the list of cross-compilation targets, and modifying the value of
java.library.pathwhen running the tests. Note that our JNI native library does not depend on any NDK methods, only common Linux libc functions for memory management orgetrandom. Since I needed to sniff the host OS and architecture to pick the right build artifact, I also added a narrower task dependency from the unit tests to cargo, by only requiring the host target, and not any Android cross-compile targets.