gradle-ndk-gtest-sample
Android NDK with
README.NDK
I have been trying to configure my Android NDK project for use with Google Test. I started with native-activity sample as the base project and began following the guides above. I inserted the code from the first link into my root build.gradle. I am really not having any success. It looks like i was able to generate the test library:
./libs/googleTest/1.7.0/lib/osx/libgtest.a
./libs/googleTest/1.7.0/lib/linux/libgtest.a
./app/.externalNativeBuild/cmake/debug/x86_64/libnative_app_glue.a
./app/.externalNativeBuild/cmake/debug/x86_64/libFOO.a
./app/.externalNativeBuild/cmake/debug/x86_64/libgtest.a
./app/.externalNativeBuild/cmake/debug/arm64-v8a/libnative_app_glue.a
./app/.externalNativeBuild/cmake/debug/arm64-v8a/libFOO.a
./app/.externalNativeBuild/cmake/debug/arm64-v8a/libgtest.a
But I don't know where to go from here. How do I actually run the tests and see if they passed?
Try something like https://github.com/DanAlbert/GTestJNI. It's an alternative test runner for JUnit and GTest that exposes GTests as if they were JUnit, so you can just run your normal androidTests and they'll run your GTests for you.
Some day I want to get this either added to the NDK or at least made trivial to add to a project as a git submodule or something, but for now you can merge the pieces of that into your project.
Related
While migrating our build tool to Buck, we stumbled upon the following issues for the unit tests in Android:
Our tests for the view model need to access R.java for asserting the right resources are referenced.
We used the java_test rule but it seems R.java is not found. There is a robolectric_test which builds the .apk but we just want the R.java file in the classpath for the unit tests.
Is there a reason there is no android_test rule.
Any plans of doing so?
We explored the code and looked that we need to see the AndroidLibraryGraphEnhancer and build the Android resources.
Any recommendations?
No plans for adding such rule because it's not clear what it supposed to do and why robolectric_test is not enough.
Buck doesn't build an apk for Robolectric tests.
You really don't want to use java_test to test Android code because Android SDK and Java SDK are different. You have to test Android code with robolectric_test because it uses Android SDK.
I am using make for building and Robolectric as a framework for running Android tests. I would like to calculate coverage of my app. For instrumentation tests I used to use emmalib. What is the best way for me to set up coverage calculation in this case? I can't migrate to gradle or maven.
Are you bound to Emma? How about using RoboElectric + Cobertura code coverage? (I think you could just use a CLI for the above combination)
So options
1.) RoboElectric + Cobertura - CLI alone probably for someone not on ANT
2.) JaCoCo might have some useful options
3.) Pure Android Testing + Emma/EclEmma
Useful Link trails to follow
Generating android code coverage though changes in build.xml and ant.properties
Android Gradle Code Coverage
https://intellectualcramps.wordpress.com/2013/08/18/code-coverage-of-robolectric-tests-using-jacoco/
https://bitbucket.org/ravidsrk/androidstarter
EDIT:
Well most of the tutorials I have come across use ant unfortunately, and I don't think it would be a bad idea for you to move to a recommended build system like Gradle so it opens up a lot options. But for JaCoCo you could take a look at here: https://intellectualcramps.wordpress.com/2013/08/18/code-coverage-of-robolectric-tests-using-jacoco/
UPDATE:
Moved this from comments to the answer section for information to anyone wanting to see this and because this is a bounty question
One solution would be to use Cobertura to generate code coverage, which can be integrated in eclipse and also run by an ant build script.
A template project of such an integration can be found here: https://github.com/adgllorente/android-cobertura-boilerplate
Note that all of the magic happens in the build.xml of the Test project. Theses tasks should probably be generalised to a custom_rules.xml file so you can still use android to update your projects.
Finally, for Gradle you have many different options:
http://raptordigital.blogspot.nl/2014/08/code-coverage-reports-using-robolectric.html
http://chrisjenx.com/gradle-robolectric-jacoco-dagger/
https://stackoverflow.com/a/25037742/2771851
Note that you can always use Gradle as a secondary build system just to generate the coverage reports. (but a second build system will introduce a lot of overhead)
jacoco sometimes does not work with Robelectric and powermock runner you can use clover an atlassian tools it is now open source tool.
I do not understand. How can I add and use Espresso in my project?
Espresso url: https://code.google.com/p/android-test-kit/
How to connect this library to my project? I would like to have an example in Eclipse.
To use Espresso for Android you have to create test project which will test your main application under test. This link contains Espresso setup instruction for Eclipse and Android Studio. And also some basic steps you have to do (with test project but not with the main app) before running your tests: adding GoogleInstrumentationTestRunner into AndroidManifest.xml file and changing Run Configurations. After you finish - take a look on examples from here.
I found Espresso jar file https://code.google.com/p/android-test-kit/source/browse/#git%2Fbin%2Fespresso-dependencies . I added jar file to my project and it's very easily =).
I am writing an android library project and trying to test it. I found testing a library project
more difficult than it has to be using my current method.
Right now, I am exporting the library project into jar file. Then I put it into the libs folder of the test project and the test target project. Then I add it to build path of both projects and run the test.
Every time I make a change to the library I have to do this again. Is there easier way to do this?
There is some reference to this in the google docs. Check out http://developer.android.com/tools/projects/index.html#testing
Basically, the easiest way is to write an application that uses the library project and then add unittests to that application.
When creating the tests via eclipse, you can choose to test modules from within your library project. This way, changes to the library project are automatically applied.
I'm a long time Java developer with many years of Java EE, Ant, Maven, unit testing, mocks, etc. I'm currently using gradle to build android apps and am looking at unit testing them. And it's got me tearing my hair out!
My reading indicates that to test an app, I have to create another app inside it in a test directory. But I'm not sure how this embedded app can see the main apps classes. I presume that google came up with this because of something to do with the manifests which are different. I'm not sure why.
Without doing this embedded app system, I've been able to get unit tests to run by including the test classes with the main classes in the APK, adding the instrumentation declarations to the manifest, deploying it and running the test runners. But I don't want to be compiling test classes with app classes and including all the dependencies so that's not really an option and I'm not really sure of the effects of the changes to the manifest as I cannot find any documentation about the effects.
None of this is understood by gradle which follows the maven system of building. Also note that the android way seems to be that the embedded sub-project (test) is dependant on the main parent project, something that is totally contray to gradle and maven.
Another option seems to be separate the test project so that it's completely outside the app project. But really, I'd like to use a similar convention to maven and simply have tests in a separate directory, along with the manifest in test resources.
Has anyone managed to get testing on the emulators running unit tests following a more maven like directory structure?
You can try Robotium. It provides lots of features for a better testcase. You can have a look at it here.
Do you have to run the unit tests in the emulator? Isn't that too slow? I've been using robolectric ( http://pivotal.github.com/robolectric/ ) which creates shadow objects that work similar to mocks. I use progaurd ( http://proguard.sourceforge.net/ ) to strip out the tests for the release build.