current logging used in the DownloadService. Hopefully the extra log
messages will help us debug problems when tests fail, particularly
remotely e.g. on BitBar's TestDroid service.
The logs are local to the device and don't contain any sensitive
additional information. The extra information helps diagnose
network issues when they occur during testing.
Once we are happy with using Spoon we can add code that automatically
takes a screenshot when tests fail. This may help us debug some of the
problems we encounter running the tests on various devices. Using Spoon
exposed a limitation/key behaviour of ActivityTestRule that references
the intended Activity under test. To account for this behaviour I
restructured DownloadTest so it simply tests the download, rather than
reading the contents of the file.
I also discovered that the tests would fail on wide-screens as the Home
menu option moves from the overflow menu to the main menu. I've modified
one test to cope. Again, once we're happy with this approach (which
involves a little extra code) we can revise all the tests so they can
run equally competently on various screen sizes.
Javscript-Bridge tests don't pass on pre-KITKAT, probably as the runtime
predates the Google Chrome engine added in KITKAT. I've implemented a
way to 'pass' the test for now, in future I hope to be able to control
which tests run at runtime.
Android Test Support Library 1.0 adds the ability to approve permissions
as part of the test. I've implemented two calls to apply the
permissions; it's hard to tell if these work especially as the dialog
still appears in the GUI on my Galaxy S6 running Android 6.0.1 however
the tests generally complete OK and the app does have access to the
SDCARD to read and write as far as I can tell. We may want to revisit
the application logic that asks-for and checks the permissions at some
point.
I needed to update the versions of Espresso and several testing
libraries. These exposed a problem which has been addressed in the app's
build.gradle. With future releases of the libraries and/or the Android
testing frameworks this workaround might not be needed in future.
network operations. This is the initial skeleton that proves the
approach can work. Future work will enable us to control whether to
fully mock network operatins, have a local download server, or use the
public kiwix download server.
have a hardware menu key, but failed on those that did. Espresso
contains two similar calls to launch the menu. Either are OK on devices
that don't have a menu key (the vast majority of devices) so this bug
was latent until I tested on a wider mix of devices.
See
https://developer.android.com/training/testing/espresso/recipes.html#matching-view-inside-action-bar
and keep reading until you reach the example for "contextual action
bar".
See also https://github.com/kiwix/kiwix-android/issues/213 for the
historical context where this problem was initially exposed. It took
working with Isaac in person for us to discover the cause.
Instead of directly copying "icudt.dat" file, copy all file in "icu"
assets directory.
The icu data filename must include the version of icu lib.
But we don't want android code to be dependent of the icu lib version.
So let's copy all files in the icu directory.
Fixes#201.
