I am using AndroidAnnotations(2.5) in a sample project I am currently working on.
Since you can annotate your classes with for example #EActivity,#ViewById,#Click which will all lead to generated compile-time code, I was wondering how one would go about creating unit tests / functional tests for any Android Annotations powered application.
I would love to hear some opinions on this matter.
Cheers,
I responded to a similar post here.
There are a couple of options available to you. You can, of course, test your code pre-generation in, what I claim, is a more unit testing style. This should test the Java code in isolation, preferably without generated code involved.
You can also test the code post-generation. The MyActivity_ classes generated by AA can be instantiated directly after compile time and test them accordingly. I claim this is edging towards an integration testing style.
While, I think it is always better to test than not to test, I think for integration tests, you should test on the hardware in a situation similar to production. This gives you a total picture of how your application will behave in a real world situation. Thus, for integration tests I prefer high level "is everything working well together" tests.
Robolectric and Robotium can help greatly in these two efforts. Robolectric allows you to instantiate you Activities in a unit test, while Robotium allows you to test selenium style directly on a device.
To recap, I prefer to heavily unit test my code without generation then do some light integration testing to make sure everything is working well together.
Related
Suppose you are tasked with adding a testing framework to an existing code base that has very very little unit testing coverage. The code base isn't insanely large yet, however, it does have areas where it's not super clean, or not very OOP or testable.
I've read a couple of good answers:
Adding unit tests to legacy code
How to approach unit testing in a large project
Best Option for Retrospective application of TDD into C# codebase
But the project I'm working on is an Android app, so it's slightly different (given lots more UI components).
I have some questions that all relate to the same issue:
What's the best way to do go back and put a bunch of tests in place?
How do I prioritize which parts to test first?
do I start with areas where it's getting called a lot (and is there a tool for code analysis like this)?
or do I go back and look at classes which in the past have had the most number of bugs?
Should I write integration tests first (given this is an Android app and also integration tests may prevent broken unit tests/refactorings) and then work in the unit tests?
Sorry for all the questions, just really looking for a good approach, more specifically geared towards retrospectively testing an Android app.
P.S. I'm curious if people know of good tools they can use for code analysis that can help bring to attention the areas in a code base in which unit testing would be most helpful.
Usually when starting with unit testing on an existing application you would want to do it iteratively - you probably do not have the time or the man power for a big upfront investment and so you want to add unit tests as part of the required work:
Write unt tests When adding a new feature - or better yet use TDD
When fixing a bug - write unit test(s) that fails de to the bug before fixing it
When refactoring old code wriute unit tests to make sure no regression bus were introduced
Id the whole team follow the three steps above in a matter of weeks you should have good coverage for the code you've been changing - depending on the size of the project.
I don't have an Android-specific answer. I hope someone comes along and adds a good one. Meanwhile: write acceptance (integration) tests for your most important features (from your product owner's point of view, not from some tool's). You'll get the most coverage for your effort, and be the most likely to prevent bugs that customers care about. Don't worry so much about unit tests; those are for details.
[That's the answer given in the third post you cite, but we're still waiting for that Android-savvy answer so let's not call this a duplicate yet.]
Do write acceptance tests and, as necessary, unit tests for new features, and write unit tests when fixing bugs.
Regarding how to find areas of the code that need tests, the first thing to do is measure code coverage. (You can do that in the Android SDK with ant emma debug install test.) Obviously code with no coverage needs tests.
Can we use JUnit for test driven development in Android ? If not, is there an alternative similar to JUnit ?
I searched a bit on google and also read a SO post Android Test Driven Development
It looks like Android was never made with TDD in mind. I wanted to be sure before I begin learning TDD and doing Android development at the same time.
I think you can completely rely on Robolectric for running your tests in JVM. You get to use JUnit4 for testing your POJOs and Robolectric provides you the support for testing the Android components.
I am also a beginner in TDD for Android Development. I find Robolectric really useful for test driving my code.
This video will tell you almost everything it provides you for unit testing the Android code.
UPDATE:
With the Android studio support and the new Android ecosystem, now unit testing can be done as a first class practice. Refer http://developer.android.com/training/testing/unit-testing/local-unit-tests.html for more details.
There are couple of good approaches to test drive the android code. The most effective ones I have found so far is using MVVM(model-view-viewmodel) or MVP(model-view-presenter) approach, where the business logic as well as presentation logic is decoupled from the view and can be easily be unit tested.
Yeah we can use JUnit for test driven development. To initiate with you can refer to following
link : http://developer.android.com/tools/testing/testing_android.html#JUnit
Following the documentation we can use the junit.framework to have unit testing done.
Here is a bit of explanation of the problem space: http://www.techwell.com/2013/04/applying-test-driven-development-android-development
The conclusion is you should use Robolectric. Unfortunately Robolectric is slow, and if you follow TDD even on a pragmatic level, you will end up with a couple of hundreds of test, that will run for couple of 10 seconds. And that is not you want to do with TDD. TDD test package should run at most in seconds.
My advise is:
Create wrapper classes around Android classes that simply call the Android class.
Write your app logic in pure Java.
Use Junit (or TestNG or whatever pleases you) to test you model/business logic
Use occasionally Robolectric for the wrapper classes (probably you won't have to use)
(You can write integration tests that use multiple classes, Robolectric, etc. but only run it on a separate Continous Integration server eg. hourly)
With this approach your logic will be more portable as well.
I'm new to testing.I've developed a application,now i need to test.I googled about testing for some time,learnt ,what different types of testing are there in general.I wrote few test cases.
Three things,i would like to know,
Is there any different types of testing for android,if yes,can you give me some links which could help me to refer.
How do generally a android user test his apps,Will he uses test frame works or generally write test cases and testing that on real phone to see how they are performing.
Is there any sample test cases written document which will give me some basic idea.
For integration testing I use Robotium. It is a nice convenient layer on top of the build in instrumentation testing. These Tests need to be running in an emulator or on a real device. It is recommended in both cases to have an extra test project (producing an additional APK) that depends on the project under test.
Personally I like to partition my app so I have one or more libraries that do not depend on Android specific classes and can therefore be tested in a regular JVM using JUnit.
There is a third way to test and that is by mocking the android classes and have the tests run in a JVM. I have not yet used it but I hear Roboelectric is a framework that allows for this kind of testing.
Android Monkey tool can be a handy little tool. I find it handy the pseudo random fashion is handy for generating unusual use cases.
http://developer.android.com/guide/developing/tools/monkey.html
I have been developing Android application for a small company and during the development process we need to do repetitive testing of some modules, So i searched tools for doing automation testing (unit testing) of the app. Android has a unit test tool however to write those test cases will itself take more time then to actually test it by hand.
I found some apps which do some great stuff and provide good charts for example Robolectric, robotium, fonemonkey4android, but am confused to what to be used, any one with any experience with the same can help.
I checked for previous questions on the similar terms like below
https://stackoverflow.com/questions/522312/best-practices-for-unit-testing-android-apps
But all the threads are very old and not so informative to decide on which to choose..
I think first you need figure out which part of your code you want to test.
For codes which doesn't related to user interface, you can test them with Robolectric. With Robolectric, the unit test code is the same to those written for java application. But it's not suitable for test ui components.
If you want to test ui, then you can choose robotium. But i always doubt whether it's worth writing tests for ui, they change too often..
I have considerable experience in making Android applications. For my new project, we have decided to do Test Driven Development (TDD). I have been getting my hands wet on Robotium for User Scenario Testing, and it works fine and looks easy too.
For unit testing, I tried to mock Context using (MockContext Android Class) but I am unable to do so. I went through this blog http://sites.google.com/site/androiddevtesting/ and through this http://sdudzin.blogspot.com/2011/01/easy-unit-testing-for-android.html , which suggests that mocking in Android apps is still very limited and hard, and have suggested to use PowerMock, jMockit, JeasyTest, or Roboelectric (in combination with Mockito and Maven) and even RoboGuice.
I would like to get any suggestions from you guys on which unit testing framework in your opinion is the best for testing Android applications. (particularly testing Android classes, possibly giving mock Contexts and other mocking features so that I can make my test cases as independent as possible). Any suggestions or pointers would be helpful . Thanks
For off-device testing, look at Robolectric
For on-device testing, look at Borachio
Bottom line: it's still very, very difficult to do well. Things are improving (the situation is dramatically better today than it was 6 months ago) but Android is comfortably the most test-hostile environment I've ever written programs for.
To do TDD in Android, I personally use all of the following:
assertj-android: assertions for Android
Mockito: Mocking Framework
Robolectric: Unit testing framework that runs without the need of Android emulator
Robotium: UI tests (Needs emulator or device to run)
Also: Using dependency injection libraries such as Dagger or Roboguice will greatly simplify your unit/integration tests. To run tests on multiple devices, consider using Spoon.
I use ActivityInstrumentationTestCase2 in the case of Activities for TDD (or BDD rather), and write normal unit tests for all logic. This also helps me separate logic from Activities.
Mobile applications by nature are UI centric. Therefore it does not
make sense to mock out the UI, even if it makes the Unit test look
like a Functional Test.
For adding Extras to intents, you can set a custom intent for the test, or do it for all tests by overriding setup.
Mocks give a lot of issues on Android, so I use stubs.
An example is given below. The Activity shows Hello World when you click a button -
public class HelloWorldActivityTest extends
ActivityInstrumentationTestCase2<HelloWorldActivity> {
private HelloWorld activity;
public HelloWorldActivityTest() {
super(HelloWorldActivityTest.class);
}
public void testShouldRenderGreetingOnButtonClick() {
activity = this.getActivity();
Button button = (Button) activity.findViewById(R.id.btn_greet);
TouchUtils.clickView(this, button);
assertEquals("Hello World!",
((TextView) activity.findViewById(android.R.id.greeting_text))
.getText());
}
}
EDIT: Things have changed since I posted the answer. Mockito now has reasonably good support for Android. And for tests, we've moved from ActivityInstrumentationTestCase2 to Robolectric, just in order to tap the sheer speed of JVM in the development phase. The Android Testing Framework is great for Integration and Functional testing, just not for Unit Tests.
To apply TDD for android, Android Testing Codelab will be very helpful to you. Code lab shows a use of the testing tool and how you can apply TDD for android.I tried it and it was very helpful to me.
Bonus: Check Clean Architecture
Android Testing Support Library provides an extensive framework for testing Android apps. This library provides a set of APIs that allow you to quickly build and run test code for your apps, including JUnit 4 and functional user interface (UI) tests. You can run tests created using these APIs from the Android Studio IDE or from the command line.
Read more about:
Espresso
AndroidJUnitRunner
JUnit4 Rules
UI Automator
Thank you :)
we have
https://developer.android.com/training/testing/start/index.html
and can able to test local(Runs on JVM) and instrumental test (Runs on Device or Emulator )
For this we need to add
Android Testing Support Library
The Android SDK includes two tools for functional-level app testing
Monkey and monkeyrunner