Our normal way of writing unit tests is using mocks via Mockito. However, LocalBroadcastManager, for some unexplicable reason, is final - thus preventing Mockito from expanding it, which prevents us to mock/spy it...
--> How can I write unit tests for a class that contain LocalBroadcastManager?
I would for example like to check that when some conditions occur etc. certain broadcasts (containing specific extras) are sent out.
Use PowerMock:
Run your test class with PowerMock:
#RunWith(PowerMockRunner.class)
#PrepareForTest({LocalBroadcastManager.class})
Then where-ever in your test you want to mock the static method, do this:
PowerMockito.mockStatic(LocalBroadcastManager.class);
LocalBroadcastManager instance = mock(LocalBroadcastManager.class);
PowerMockito.when(LocalBroadcastManager.getInstance(context)).thenReturn(instance);
Related
In my android app, there the following code:
BluetoothManager bm = (BluetoothManager)activity.getSystemService(Context.BLUETOOTH_SERVICE);
BluetoothAdapter ba = bm.getAdapter();
I want to do Unit Tests using Robolectric. I am using Robolectric 2.2.
But I found that bm is null, and I don't know how to mock it.
The challenge
The challenge with testing for bluetooth and other system services is that these classes are all final.
The hard way (skip and go to powermock solution if you like)
So if you want to inject anything else you need to make a wrapper around the final class and then provide an implementation forwarding to actual bluetooth classes and an alternative one that mocks your stuff. But then all coded needs to be updated to use that wrapper instead of the final classes directly.
PowerMock solution
PowerMock however should be able to handle these final classes. The summary (follow link for more detail)
Use the #RunWith(PowerMockRunner.class) annotation at the class-level of the test case.
Use the #PrepareForTest(ClassWithFinal.class) annotation at the class-level of the test case.
Use PowerMock.createMock(ClassWithFinal.class) to create a mock object for all methods of this class (let's call it mockObject).
Use PowerMock.replay(mockObject) to change the mock object to replay mode.
Use PowerMock.verify(mockObject) to change the mock object to verify mode.
I'm trying to write a batched instrumentation test (using ActivityInstrumentationTestCase2) for a particular Activity where I change the intent each time the test runs. I can do this with a single test, and just loop through stopping and restarting the Activity with the new intent, but this is not what I want. One reason is they really should be separate test runs. The other reason is, I'm using Spoon to generate a report when the tests finish, and the report will rightly think I only ran one test.
What I would like is it to treat a single test as a possibly infinite number of tests, and pass the data into the test each time the test runs.
Unfortunately you can't use Theories because it results in a RuntimeException where the InstrumentationTestRunner can't find my tests. Anyone have any luck with this?
You could always just create a "testing" intent. In order to simulate the relaunching of the application, make a method or several methods that reset all your static variables between tests. Then you can test the classes from within a testing intent inside the application itself using
assert("value", MyClass.myMethod);
resetStatics();
assert(true, MyClass,myMethod);
resetStatics();
I don't know how much this will help you, if at all, but this is how I started writing my own tests.
I recently discovered that you can add a public static Test suite() method to a test class, and when you run just this single test class, InstrumentationTestRunner will run the Test returned by this method. This is helpful because suite() can explicitly call any constructor of your TestCase, including one with parameters.
I have troubles with my Robolectric unit test.
I can assert without problem that a click started a new activity when the listener uses the method startActivity( Intent )
But it seems Robolectric has trouble when a new activity is started with the method startActivityForResult(Intent, int) : putting some breaks in the code made me figure out that the activity wasn't started ( and just changing for method startActivity( Intent ) made the assert pass).
Is that normal ? It's a pity since the first activity of my app uses startActivityForResult(Intent, int).
Did someone manage to make tests with this way of launching activities ?
Thanks for your help ..
The short Answer to your question is that, due to the way Robolectric converts Android classes to code that executes in the JVM, a lot of their functionality doesn't behave as you'd expect. Many system callbacks won't execute, and you'll have to rely on what Robolectric provides in their Shadow implementation of classes. (See the link provided by #Steven_BDawg).
The long answer: It may be possible to implement this whole flow in one big test, but it's not what the framework is designed for.
Robolectric and Unit Testing in general aren't meant to be used in the way that you describe. The Unit Testing page on wikipedia states that one can view a unit as the smallest testable part of an application. A unit testing suite should contain many lightweight tests, where each test isolates a bit of functionality in your app and ensure it's working properly.
Consider a basic Application that contains two Activities, A and B. Activity A displays some information about a topic, and Activity B allows the user to select which topic to show in A. When the user moves from Activity A to Activity B, B gets called with startActivityForResult() and should return to A with the selected topic.
Now say we want to Unit Test this flow of A getting the result from B and displaying the data. We can break this up into two tests:
Activity Under Test - Activity A. In our test, we'll create a new instance of Activity A. In the Robolectric Test, we create the Intent that we expect B to return to A, and call the shadow method receiveResult() for A, filling out the arguments with a result code of OK and this Intent. After receiveResult(), run your assertions. You now know that Activity A handles the result properly!
Activity Under Test - Activity B. In our test, we'll create a new instance of Activity B, setting it up as if it were started for result from Activity A. In the Robolectric Test, we'll perform all actions needed to select the data, create the intent we'll send back, then run assertions on the intent to ensure it was created correctly.
This is a very simple example. These two steps could probably be broken out into many more tests, as, again, each unit test should only be testing the smallest unit of functionality that your app can be broken into. The example is mainly to help you start thinking in a unit testing kind of way. I've found that as my understand of unit testing deepens, the way I write code has changed. I try to avoid writing methods and classes in such a way that they do too much work and cannot be properly unit tested. As a rule of thumb, code that's easy to unit test performs very specific operations which are readily apparent when reading the code for the first time.
Finally, if you want to take this a step further, mocking frameworks can greatly aid your ability to Unit Test. Mockito is a mocking framework I've had success with in the past. The purpose of a mocking framework is to create stub Objects whose behavior you tightly control. Mockito (or any other Mocking Framework), will allow you to define an object that extends from any type you need and only implement the methods you need. You'll be able to directly control the response to any of these method invocations. This aids Unit Testing because the only real object that you'll need is the Object Under Test; by Mocking all other objects, you'll have a better sense of whether or not the Object Under Test is behaving properly because all other behavior is explicitly defined by you, the tester. (And yes, this does lead to lots of extra code, but such is the life of a good unit tester. However, as previously stated, as you get more comfortable with unit testing, you may find yourself writing methods that require less mocking and are more conducive to writing tests. Some coders will even write their unit tests BEFORE they code, in order to keep their code tight and focused on a single purpose)
Hope this helps!
I did some Google'ing for you. I don't know if this will definitely help you or not, but I think it is a good start!
Roboelectric: Testing startActivityForResult() and onActivityResult()
I'm using the android.test.runner library and the AndroidTestCase etc. to create some unit tests. I'm finding it useful, but one test requires access to the application object. Usually I just get that from the activity context, e.g.
AppState appState = ((AppState) myActivity.getApplicationContext());
However, the unit tests are in a class which extends AndroidTextCase, and as far as I can see there is no getApplicationContext available. There is a getContext, but I'm not clear if that's what I want. What's the best course of action?
Are you testing your AppState object, or trying to test something else which relies on it?
If you are not testing AppState in this instance can you use a tool such as Mockito to mock up an AppState object for the purposes of your test.
I have question on the Android API. Android API provides a class called "Instrumentation" class. What is the use of this class? Is the Instrumentation class be used only together with Junit for unit testing.
Can Junit framework can be used to test the methods of the Android API without using the Instrumentation class.
Since Junit package has been included in the Android package, I hope we dont need to use install separately for unit testing.
I would appreciate if you could provide me the information as i can't find these clear information anywhere on the Web.
If we use Junit test framework to test the Android API, can we have test results in the UI format rather than test format.?
Thanks a lot. Apprecite your time.
Regards,
Riyas
The Instrumentation class allows the test case to subscribe to various application events (keypresses, etc), and also programmatically control the UI to enable functional testing of your application.
Therefore, you technically do not need the Instrumentation class for Junit testing if all you are doing is unit testing, and not functional testing of the UI. You could just extend TestCase which does not provide any Instrumentation support.
Here is a link with some fairly good descriptions of the various test classes.
Junit is included within Android and will not need to be installed separately.
Instrumentation API is basically used to inject various kinds of events to the UI so that the application can be stress-tested. You can create an arbitrary event like tapping on the screen and inject it using instrumentation API which is basically like a pseudo event generation.
Instrumentation class is a base class for test frameworks, this provides a very specific functionality, It also provides API to invoke test on device/emulator using ActivityManager Interface via ADB. Also, it can gets back the results to the development machines.
By overriding this class you can enjoy all the context and helper classes you need to run your tests.
Below is a sample implementation, I wrote to explain you the functionality.
public class SampleInstrumentation extends Instrumentation {
#Override
public void onCreate(Bundle arguments) {
super.onCreate(arguments);
Bundle bundle = new Bundle();
bundle.putString("whatisthis","thisiswhat");
finish(0,bundle);
}
}
Manifest:
...
...
</application>
<instrumentation
android:name=".SampleInstrumentation"
android:targetPackage="com.commons"></instrumentation>
</manifest>
Now if you run this command from your development machine.
adb shell am instrument -w -m com.commons/com.commons.SampleInstrumentation
Your instrumentation class onCreate methods get called and you will get some binary encoded response on your console containing data from the bundle you passed to the 'finish' function.
"
whatisthis
thisiswhat
I hope this will make you understand the functionality specific to this base class. For the sake of some motivation, I would like to add that the new android testing framework androidx.test gets compiled with our app (not part of OS and can be modified) directly extends the Instrumentation class (part of Android Framework/OS implementation). Hence you can write your own implementation of a whole new testing framework just by using this class.