I am trying to write functional tests for an android application. The problem is that most functional testing frameworks that I have explored (calabash-android, robotium) have a limitation on the number of activities from different applications that can be tested in the same test. So if in one workflow I need to select some contacts from the android contact picker I cant test that entire flow because the contact picker activity is part of the android contacts application and the framework can't test an activity from my application and the contacts application at the same time.
One possible solution my team thought of was to mock out the call to the contacts activity to return a dummy intent with contact information so that our application workflow can be tested. We are trying to use mockito to achieve this. However I am stuck pretty early on. Here is what I am trying to do
MyActivity mockActivity = mock(MyActivity.class);
when(mockActivity.startActivityForResult(<?>,anyInt())).thenReturn(fakeIntent);
I am not sure what to put in the first parameter in the second line. I have tried Intent.class and android.content.Intent.class however it throws a compile error. If anyone has worked with mocking activities using mockito, some help will be greatly appreciated.
P.S. - If I understand correctly mocking is used more in unit testing than functional testing. So these tests would be more of a hybrid. If anyone has a better suggestion on how to go about these functional tests on android I am all ears.
It's hard to answer this without knowing the signature of your startActivityForResult method, but the general idea is to use any(Xxx.class), where Xxx is the type of the parameter. So either
when(mockActivity.startActivityForResult(any(Xxx.class),anyInt())).thenReturn(fakeIntent);
or the (kind of equivalent)
doReturn(fakeIntent).when(mockActivity).startActivityForResult(any(Xxx.class),anyInt());
The issue is that you cannot really "mock" (actually "spy") on the activity you're testing since it is created out of your control by Android's instrumentation code. In a unit-test environment where you would have control, you could follow the mock(MyActivity.class) or spy(myActivityInstance) path (spy would actually be better because you could re-use most of the activity's original implementation), but here not.
The only solution I found for this dilemma was to move certain functionality out of the activity into utility classes, ideally utilizing roboguice for that (#ContextSingletons can be used to process activity results). Then, in your test project, you would create your own test guice injector, set that as base application injector before you call getActivity() for the first time and then let the activity work on your mocked utility class.
I outlined the complete process here.
Related
I want to some feedback on why I should use mockito when testing my android application and also does anyone have any real examples of mockito would be extremely useful.
Such as a git project with various use cases of mocking android tests.
Mock objects are useful when you want to test part of an application when either the rest of the application isn't written yet, or when you don't want to actually have the side effects that the real code causes (such as writing to a database).
Mocking objects is commonly used it unit testing.
Unit tests are made to assure that the flow of instructions in your code is correct, and the logic is OK, but doing it separately from other classes/objects. Just one class at a time.
So, when your code makes use of any object of other class - you mock it and it behaves like correct object of mocked class, without actually making object of that class.
I suggest you reading about unit testing, injection, mockito.
Hope it helps you to get the idea behing mock.
I have the whole project for tablets with resources and already have bunch of test cases written in combination of Robotium, Android and JUnit APIs
In a project which under testing is used special attribute for one of activities android:process=":remote". At the point where activity with this attribute already loaded I can use Robotium methods but can't get access to the elements on current screen. So seems like I should relaunch instrumentation or initialize new instance of Solo. I tried to do this, but no help, seems like I can't relaunch it in other process from my test. Maybe someone have an experience of testing such kind of applications and know how to implement it with Robotium or using directly android.test API?
You can use IUAutomator, but it works on api >= 16:
http://developer.android.com/tools/testing/testing_ui.html
You can always use monkey runner:
http://developer.android.com/tools/help/monkeyrunner_concepts.html
however it's based on x,y
There is no option to use robotium, neither instrumentation to test multiple processes.
I am trying to get more experience on JUnit and its usage in Android.
Referring to this official Android training Parsing XML data I wonder if anyone can provide with an example on how to test some of the used methods.
Particularly how would you test the methods included in the class StackOverflowXmlParser and the methods loadXmlFromNetwork() and downloadUrl() [class NetworkActivity.java]
The best advice I can give you on unit testing is to first really understand what a unit of test is. When I write tests, in particular Unit Tests, I make sure my unit of test is a single class. EVERYTHING ELSE is mocked, and my test makes sure every public method on the class does what it promises.
That said, the methods you are asking about are EVIL UNTESTABLE CODE. It's a bit shocking to see code like this come from a Google engineer. My glancing guess is it's a front end web developer because the variables are all declared at the top of the method, Javascript style and initialization of every local variable that doesn't have a value to null suggests whoever wrote the example isn't very experienced with Java.
You would have to significantly refactor the methods to get them into a testable state. For instance loadXmlFromNetwork presents an API that lies. It isn't "loading" xml from the network, it's also parsing it into a List<Entry> then after that is done, it does more by cramming data from these entries into an HTML formatted String and then returns that.
The first problem with just this method alone is that it's creating objects inside of itself, instead of asking for what it needs. This presents a problem for testing because you can't mock these objects to test the logic. In a test you wouldn't want to have to make a network dependency, so you'd want to mock the HttpURLConnection and mock the behavior to exercise YOUR code.
To point you in the right direction, watch this video from Google's lead testing evangelist:
http://www.youtube.com/watch?v=wEhu57pih5w
I'm developing an Android application with database storage.
I want to test some classes that I use to access database.
I've found ActivityInstrumentationTestCase2 to test Activities but I haven't found anything to test classes.
How can I do that? I haven't used jUnit before.
Thanks.
I always use AndroidTestCases when writing unit tests for the Android platform. They provide access to a Context instance (if required), but otherwise work like the standard JUnit test class. You may also need to look at AndroidTestRunner to test your classes. There are some good tutorials out there; now that you know what to look for, I'm sure you can find them. Happy hunting! :D
Android provides various packages for testing like
AndroidTestCase
ApplicationTestCase
InstrumentationTestCase
ActivityInstrumentationTestCase2 ActivityTestCase
I need to know how to decide which package is best suitable for testing my app. Some info is provided in this link
http://developer.android.com/reference/android/test/package-summary.html
But I need more clarity on this...
TestCase – Plain old JUnit test case. It can be extended to test utility classes that are not tied to the Android framework.
AndroidTestCase – It extends JUnit’s TestCase. It’s a lighter
testing class compared to
ActivityTestCase. It doesn’t need to
launch an activity to run it. Its
getContext() method allows you to get
an injected context if you need one.
Since you can get a context from this
class, you can inflate your UI objects
to test their behaviors.
ActivityInstrumentationTestCase2 – It’s the newer version of ActivityInstrumentationTestCase. ActivityInstrumentationTestCase is deprecated in Android SDK 1.5. It’s a heavier testing class compared to AndroidTestCase. It provides UI and functional testing for a single activity. You can get an injected activity that you are testing on by calling its getActivity() method. The activity being tested is launched and finished before and after each test.
ActivityUnitTestCase – It gives
the tested activity an isolated
environment. When using it to test an
activity, the activity is not attached
to the system. This gives you more
control over what kind of environment
that you want your activity to be
tested in.
ApplicationTestCase – It provides testing for Application classes. It can be used to test the life cycle of an application.
InstrumentationTestRunner – The runner that runs the Android test
cases.
I just found this..Hope this helps for others...If u want more details like when and how to use, see the APIDemos test application in the samples directory within android SDK.
Please see the class hierarchy graph drawn by myself using PowerPoint.
The accepted answer gives enough info in words. I just to make it clear using graph :)
For the InstrumentationTestCase #Zorb asked, it's parent class for ActivityTestCase among others. It enables you to call the getInstrumentation method to get an instance of instrumentation so that you can operate application, activity, and so on.
INTRO
To clarify your question and collocate the classes you are asking for, it is essential BEFORE to divide testing in two categories. JUnit tests (in theory plain Java) and Instrumentation tests (that also are part of the JUnit test package but allow you to test more SDK Android related functionalities).
Traditional JUnit tests isolate a section of code and run a test. Instrumentation tests access instead more inclusively the android components. BUT ALSO THE INSTRUMENTATION TESTS DERIVE FROM THE JUNIT PACKAGE although they are instantiated in the system even before any application code is run and this explain why are slower, furthermore they need an emulator or phone that run the app you are testing to be executed.
(Follow in Bold all the class you mention, but there are others even more used that I will write without without the bold character).
****FIRST PART**(Junit tests)**
A) Junit tests that extend TextCase (are usually faster than Instrumentation, and combine well with Mock framweworks)
AndroidTestCase: It allows to have access to the Context of the Activity you are testing and their resources, it is a base class that extends more specialized subclasses, it is ideal to access databases, filesystem data. You can easily call getContext() and access the Resources without establishing a direct contact with the Activities as will be with Instrumentation tests.
ApplicationTestCase that controls the environment where you text the application, mainly the context and the life cycle. Other really useful extensions of AndroidTestCase allow you to control Loaders,Services,and Content Providers, but for some reason still not any Broadcast receiver that you can call it [indirectly][1] with the method InstrumentationRegistry.getTargetContext() and then instantiating BroadCastReceiver. Also it is really common to use different Mock framework with Junit that is usually faster than InstrumentationTests
-.-.-.-.-.-.-.-.--
****SECOND PART**(Instrumentation tests)**
B) Instrumentation tests, that extend TestCase
Are considered functional tests, focused more to insure that they work well with the user side, the View part of MVC.They are usually slower than the other mentioned category
InstrumentationTestCase is a base class useful to send key events to UI to simulate QWERTY keyboard keys or DPAD buttons,also it launches the Activity that have to be tested, and even Intents
ActivityTestCase Usually is not used alone,it just has common code for the subclasses, but in the case you are not satisfied by the 3 classes that inherit from this one(see below) like a new future component you can use it by the time will not exist a TestCase class dedicated.
ActivityInstrumentationTestCase2 is the most used Instrumentation class to write functional tests, from the constructor is invoked the instance of the Activity to test. Basically you call the activity with getActivity() and you can pratically run any method of that Activity.
ActivityInstrumentationTestCase, is deprecated, and ActivityUnitTestCase that although is under the Instrumentation is more similar to an unit test
I found this tutorial from droidcon 09 to be really informative. Complete with downloadable working source code examples.
Edit: The link seems to be dead, as pointed out in comments.
It walks through creating a Celcius to Fahrenheit temperature converter test-first using ActivityInstrumentationTestCase2, TestCase and AndroidTestCase.