I have been using android studio for some time.(still learning) and till date i haven't used the java files in the test folders. i.e the one's marked here :-
Is it necessary for a project or can we just delete those files?
If it is necessary, what is its use and how can we use it ? (any reference would be great).
If anyone could rephrase the question in a better way,it would be better.
Those are for tests. The androidTest is for instrumented tests while the test folder is for unit tests. You could delete them if you do not plan on using it, but it also does not harm your project.
See here Test Your App
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 do have a project with an app and a library module that contains JNI code. I added a test class to the 'androidTest' folder in order to test all this in a device environment.
At the time doing, Android Studio 2.2.2 was able to identify the code as test (adding all the nice icons to run the whole class test and so on).
Now (a large number of commits and git rebasing later) I want to do some more work, but Android Studio refuses to accept the code as test code, although gradle itself (invoked with :libname:connectedAndroidTest) does perform the tests and writes timing info into some XML in the ./build/outputs/androidTest-results/connected of the library module folder.
The AS editor marks all unit testing related imports in red. When I try to resolve the "problem" AS suggests to "Add library 'runner-0.5' to classpath" although build.gradle already contains that reference.
AFAIR I was also able to select the library module in the "Module" setting in the General tab of the Android Test run configuration. But that doesn't work anymore.
What puzzles me is, that I some had this all working from within the IDE and now it doesn't work anymore. Although the gradle call will still run the test cases that the compiler doesn't complain about anything...
Any ideas anybody?
PS:
I do know that I can move the "androidTest" code into a differen module. However I do already have 10+ modules in my project. And since gradle is able to run the test, why is Android Studio not anymore?
I'm trying to get Robolectric up and running by following thecodepath tutorial on github. However, when running the test, eclipse tries to download org/robolectric/android-all/4.3_r2-robolectric-0/android-all-4.3_r2-robolectric-0.jar. What exactly is this 30+ mb .jar file for? Is it supposed to replace the android.jar file from the tutorial?
Let me first ask а question: Why do we need Robolectric for unit testing Android?
And the answer is that android.jar is shipped with contracts of classes and utilities methods only. That means every method, every function and constructor in this jar just have one line of code:
throw new RuntimeException("Stub!");
You can only compile your code against this jar and never run on a desktop JVM. If you try to run then you will get an exception thrown as soon as you try to instantiate an android class or call any android utility method.
Robolectric tries to solve this problem. From the beginning it customises ClassLoader and every call to the android code is replaced with a Robolectric implementation. That gave us possibility to test our code on desktop JVM. But that is quite hard to re-implement whole android as well you trap in situation when you test against something different that is present on devices.
So the strategy was changed from Robolectric version 2. It tries to use as much as possible android source code which is open sourced from the beginning. That is why the first run of your tests Robolectric downloads and caches own android.jar which is compiled from android sources. It is done to make sure that our tests environment behaviour is close to behaviour that we have on the devices.
I would recommend you to read more about Robolectric on their blog, google group. As well you can find plenty of presentations on slideshare and youtube about it. And I encourage you to contribute to Robolectric project on github as soon as you are confident with it and want to give back your gratitude to the community.
I had the same problem when I was trying to set up Robolectric for the first time. The reason for my problem was, my project src files were in the package:
com.example
But my test files were not inside a package. When I moved my test files to:
com.example
The problem got resolved. I hope this might help.
I've got my main application project, and then a second project for my tests. Is it good practice to store all types of tests in that test project, or should some reside in the main application project?
Should I keep POJO JUnits (ones that test non-android derived classes) in my main project, or group them all together? I can't see anything on the Google documentation that advises where to locate tests.
Thanks
Rather than creating two projects, its very good practice to create a second 'source' folder in the original android (or java) project and put your tests in that. When you export as an app, you can exclude that source folder from the compiled application.
The Android test documetation says
... the best approach is to add the test project so that its root directory tests/ is at the same level as the src/ directory of the main application's project.
There is even an illustration of the directory structure in the documentation.
Jarl
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.