Android studio creates a test folder called androidTest with an ApplicationTest.java file by default upon creating a new project. It's obviously used for testing, but what kind of testing? In what circumstances should I use the test folder when developing an Android app?
but what kind of testing
The instrumentation testing that centers around the technologies in the Testing Support Library (e.g., Espresso, UI Automator).
You can do Android Instumentation Tests, or regular Junit4 testing. I recommend you do some kind of testing, if only to prevent regression of bugs. I favor test driven development (TDD), cf http://blog.pivotal.io/labs/labs/tdd-android-pov
Related
I'm a fanboy of Test-pyramid application in software development and want the same to be applied in Mobile software development as well.
For this, I'm desiring to leverage both Appium (for functional tests) and Espresso (for Integration Tests), and have the following questions:
The structure of my tests in Android Studio with Gradle has only 2 folders: app/src/test and app/src/androidTest.
The former test is meant for writing Unit tests with JUnit. The later for functional tests; and I'm using espresso tests for integration-testing making use of the latter directory.
I know I can create a separate project for Appium and write functional tests. But prefer to have those as part of the project in separate test source directory, so that it can be run at different intervals in my CI pipeline. How do I go about doing this? Is it possible to create another source test directory like app/src/functionalTest? Pointers to sample projects in github or resources is well appreciated.
I have created a Mono for Android VS2010 project and added NUnit tests.
It seems Mono for Android does not support NUnit according to this post from Xamarin:
https://bugzilla.novell.com/show_bug.cgi?id=644813
Are there any testing frameworks that do run when in a Mono for Android project?
no, nunit does not work nor do any other frameworks. the intent of monodroid and monotouch is to provide a .net development environment that allows you to easily port business logic between different environments. as a result you can't really test android/ios specific code, but you can test generic .net business logic code. in the monodroid projects that i write, i create 3 projects in the solution, one is the android project, another is a .net library that holds all of my non-android specific logic and the final project is a nUnit test library against the .net library. I then add my logic code files into the android project with linked files. monodroid project files can not be tested, but .net codes files linked into monodroid projects can be tested with what ever framework you choose.
There is now a Mono for Android test runner for NUnitLite (0.6). This allows you to run some (or all) your unit tests inside the emulator or on device(s).
It's very similar to Touch.Unit which provides a runner for MonoTouch on iPhones and iPads (iOS) and feature parity is planned (i.e. adding the network logging).
Disclaimer: I wrote the runner (but the most interesting code is NUnitLite and the, several times forked, MonoDroid.Dialog library ;-).
For UI testing on actual devices, LessPainful announced earlier today that Calabash for Android supports it since version 0.1.0:
[...] we now support Mono for Android.
[...] Currently you can only test Release builds of your app. If you need to test Debug builds let me know.
I've not used Calabash with Mono.
I created a version of NUnitLite that targets MonoDroid.
It's worked quite well for me so far.
It needs to run directly on the emulator or device at the moment. If someone were able and inclined to write a runner for it, I'd welcome the input.
Check it out here: https://github.com/SpiritMachine/NUnitLite.MonoDroid
I have a Robolectric test project setup, but I'd like to also run these tests on my device to check that I don't get bit by JVM vs Dalvik implementation differences.
Unlike robolectric tests, I won't run these tests frequently. My concern is that there's little effort to maintain the test suite and that they verify actual device functionality.
What's the best way to do that?
What I've currently got:
My robolectric test project as a test case TestPackage. I created an Android Test project with a test case TestRoboOnAndroid. It creates a TestPackage and has a test for each test in TestPackage.
Right now, every time I add a test to my robolectric suite, I need to manually add it to my device suite. Is there some way to do that automatically with reflection?
Also, Robolectric uses JUnit 4 (by default) and Android uses JUnit 3. So I have to write all of my Robolectric tests using JUnit 3 style (importing from junit.framework instead of org.junit).
The whole point of Robolectric is NOT to run it on the device and the design is based on that. If you want to run something on the device look at the default instrumentation tests from the SDK or Robotium.
It is totally feasible to run your Robolectric tests on the JVM and in addition create Robotium tests that rely on device specific interaction (e.g. creating screenshots, hardware differences...) and run on devices and emulators all combined into one build.
The easiest way to do that is to use the Android Maven Plugin.
I use a tiered system, where I prefer earlier tiers where possible:
Pure unit tests. I try to make as much code as possible fully independent of Android APIs, and then use "pure" unit tests which can run on any JVM. These tests are the fastest, and it helps keep code that has no need to be Android-specific portable.
Robolectric-supported unit tests. Where my code has only small dependencies on Android APIs, that can be satisfied by Robolectric shadows, I test it with Robolectric. There is a little more setup time for Robolectric compared to pure tests, but it's still faster than starting/running on an emulator.
Android framework tests. Where Robolectric doesn't cut it - either because the shadows don't exist, or because I'm heavily using Android APIs (and therefore want to test against the Real Thing) - I write test that run on the emulator/device with the default framework.
The point of the tiers is to keep things as simple as possible, which keeps the full suite faster and helps promote cleaner code.
We use Robolectric for unit testing against the JVM and Calabash-Android for system testing against Dalvik. Both can be integrated into our Jenkins CI build and between the two tools I feel that we cover all the bases.
Is anyone using Junit and Android? Or is that just a worthy hope? Is there a tutorial anywhere?
Android has great support for JUnit 3
From Testing Fundamentals on Android Developers:
The Android testing framework, an integral part of the development environment, provides an architecture and powerful tools that help you test every aspect of your application at every level from unit to framework.
The testing framework has these key features:
Android test suites are based on JUnit. You can use plain JUnit to test a class that doesn't call the Android API, or Android's JUnit extensions to test Android components. If you're new to Android testing, you can start with general-purpose test case classes such as AndroidTestCase and then go on to use more sophisticated classes.
The Android JUnit extensions provide component-specific test case classes. These classes provide helper methods for creating mock objects and methods that help you control the lifecycle of a component.
Test suites are contained in test packages that are similar to main application packages, so you don't need to learn a new set of tools or techniques for designing and building tests.
The SDK tools for building and tests are available in Eclipse with ADT, and also in command-line form for use with other IDES. These tools get information from the project of the application under test and use this information to automatically create the build files, manifest file, and directory structure for the test package.
The SDK also provides monkeyrunner, an API testing devices with Python programs, and UI/Application Exerciser Monkey, a command-line tool for stress-testing UIs by sending pseudo-random events to a device.
This document describes the fundamentals of the Android testing framework, including the structure of tests, the APIs that you use to develop tests, and the tools that you use to run tests and view results. The document assumes you have a basic knowledge of Android application programming and JUnit testing methodology.
I have been using Roboelectric which is awesome because it does not launch the simulator making the run time for the tests very very quick. A sample project is provided as an example and can be found here at github
You can also use Robotium to drive the UI from within JUnit for more functional style testing.
"Note that the Android testing API supports JUnit 3 code style, but not JUnit 4." (Source)
If you want to use JUnit4 or have existing JUnit4 tests you can use JUnit4Android.
Im pretty sure the answer is no, but im using the new IntelliJ EAP version and have a project i worked on a while back which was just written against JDK 1.6 for an applet based application.
However now i could see how it could be useful in an android app that im interested in creating.
Do i now have to re-write all the code/tests again targeting the android sdk or can i just drop in my existing JAR file and only use android for the UI layer.
Its just android seems to make testing WAY harder than it needs to be, and i have alot of existing tests written and working, if it wasnt so hard to just write a quick unit test (standard Junit #Test style) i wouldnt mind porting, however i just dont get the whole instrumentation thing, as i dont need a UI at the moment...
Anyway so back to the point, can i use my existing JDK built code in an android app?
No!
Android uses the "Dalvik" VM from project harmony which uses a different set of bytecodes which are incompatable with the standard Java JVM bytecodes.
This was done both to optimise the VM for opreration on mobile platforms, and, probably more importantly to try and avoid Copyright and patent disputes with Sun and now Oracle.
More info here
However there is a tool called "dx" which can perform the conversion in the dev environment.
Okay, let me clear up your confusion.
Jars are converted to dex Dalvik bytecode during the compiling process thus you can use 3rd party jar libs.
However, in your case because its applet which has a different application lifecycle yes you might have to re-do it to get it to work in android.
As far as testing instrumentation is used on all java mobile development even JavaMe. It basically means that the Junit tests are run in the emulator or device but in android's case you are using android mock objects to test android specific things.