I have the following test code. I am trying to test whether a list is being populated from SQLite database.
public class ViewIssuesActivityTest extends BaseActivityTest<ViewIssuesActivity>{
private List<Issue> issues;
public ViewIssuesActivityTest() {
super(ViewIssuesActivity.class);
}
public void setUp() throws Exception {
super.setUp();
issues = new ArrayList<Issue>();
issues.add(new Issue("Trial","Desc","Location","ImagePath"));
IssueRepository issueRepository = mock(IssueRepository.class);
doAnswer(new Answer<Object>() {
#Override
public List<Issue> answer(InvocationOnMock invocation) throws Throwable {
return issues;
}
}).when(issueRepository).getIssues();
activity.setIssueRepository(issueRepository);
}
public void testNumberOfIssuesRecorded() {
ListView listView = (ListView) activity.findViewById(android.R.id.list);
assertEquals(1, listView.getCount());
}
}
My BaseActivityTest code is:
public class BaseActivityTest<T extends Activity> extends ActivityInstrumentationTestCase2<T> {
protected T activity;
public BaseActivityTest(Class<T> activityClass) {
super(activityClass);
}
#Override
protected void setUp() throws Exception {
activity = getActivity();
}
}
My ViewIssuesActivity is as follows:
public class ViewIssuesActivity extends ListActivity{
private IssueRepository issueRepository;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(com.change.kranti.R.layout.issues);
issueRepository = new IssueRepository(getApplicationContext());
List<Issue> issues = new ArrayList<Issue>();
issues = issueRepository.getIssues();
ArrayAdapter<Issue> adapter = new ArrayAdapter<Issue>(this,
android.R.layout.simple_list_item_1, issues);
setListAdapter(adapter);
}
}
The issue is I get error: expected<1> got <0>
I think the issue is the onCreate method is getting called before the issueRepository is created.
I want to mock the IssueRepository and test my list getting populated.
What is the issue with my code or is there a better way to test this functionality.
Any help will be appreciated.
You are right. The issue is that the onCreate method gets called before the mock issueRepository gets injected. When you call getActivity in the context of an ActivityInstrumentationTestCase2, all the usual life cycle methods get called (i.e., onCreate, onStart, and onResume). When your test code calls setIssueRepository, it's already too late, the issues have been fetched from the repository.
The best solution I know in this kind of case is to use dependency injection, whether by hand or using a DI framework.
It's not clear what you're trying to do.
You can't run two tests simultaneously against the same class. The ActivityInstrumentationTestCase2 class is essentially a controller and wrapper for the Activity under test, but it can only control a single Activity, and you can't control the same Activity with multiple instances of ActivityInstrumentationTestCase2.
To set up an app for test-driven development, try to use as many POJOs (Plain Old Java Objects) as you can. Limit the Activity testing to stuff such as sending Intents or integration between POJOs that you can mock.
ActivityInstrumentationTestCase2 is a JUnit TestCase subclass, but it has limitations.
Related
I have an application which displays data (posts) from a web API.
A background service syncs this data at some unknown time and saves it.
When visiting my main activity it loads this data and displays it in a RecyclerView
The loading is handled via a singleton class
I currently test the main activity as follows
#Rule
public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(MainActivity.class);
#Test
public void testDataLoad() {
int postsTotal = DataSingleton.getInstance().getPostsCount();
ViewInteraction empty = onView(withId(R.id.empty_view));
ViewInteraction recycler = onView(withId(R.id.recycler_view));
if (postsTotal == 0) {
empty.check(matches(isDisplayed()));
recycler.check(matches(not(isDisplayed())));
} else {
empty.check(matches(not(isDisplayed())));
recycler.check(matches(isDisplayed()));
recycler.check(new RecyclerViewItemCountAssertion(greaterThan(postsTotal)));
}
}
I know that this can't be the right way to write tests. I want to be able to test both with an empty data set and a non-empty set so that the if-else is two separate tests. The only way I think I can achieve it is to mock the data.
Is there another way?
Can I use Mockito to make the MainActivity use mock data without modifying the production code? Is my only choice to make it inject either real or mocked data providers in place of my singleton?
Is it better to just uninstall and reinstall my app each time so there is no data to start with and then continue with real data testing?
Android Activity are heavyweight and hard to test. Because we don't have control over the constructor, it is hard to swap in test doubles.
The first thing to do is to make sure you are depending on an abstraction of the data-source rather than a concretion. So if you are using a singleton with a getPostsCount() method then extract an interface:
interface DataSourceAbstraction {
int getPostsCount();
}
Make a wrapper class that implements your interface:
class ConcreteDataSource implements DataSourceAbstraction {
#Override
int getPostsCount() {
return DataSingleton.getInstance().getPostsCount();
}
}
And make the Activity depend on that rather than the concrete DataSingleton
DataSourceAbstraction dataSourceAbstraction;
#Override
protected void onCreate(Bundle savedInstanceState) {
super(savedInstanceState);
injectMembers();
}
#VisibleForTesting
void injectMembers() {
dataSourceAbstraction = new ConcreteDataSource();
}
You can now swap in a test double by subclassing and overriding injectMembers that has relaxed visibility. It's a bad idea do this in enterprise development, but there are less options in Android Activities where you don't control the constructor of the class.
You can now write:
DataSourceAbstraction dataSource;
//system under test
MainActivity mainActivity
#Before
public void setUp() {
mockDataSource = Mockito.mock(DataSourceAbstraction.class);
mainActivity = new MainActivity() {
#Override
void injectMembers() {
dataSourceAbstraction = mockDataSource;
}
};
}
I am trying to test a Fragment I've created in Android. I have complete control of the code, so I can change it as I see fit. The issue is that I'm not sure what design pattern I'm missing to make it reasonable.
I am looking for a way to mock objects in Android that are not passed as parameters. This question suggests that anything you might want to mock should be written to be passed as a parameter.
This makes sense for some situations, but I can't figure out how to get it working on Android, where some of this isn't possible. With a Fragment, for example, you're forced to let much of the heavy lifting be done in callback methods. How can I get my mocked objects into the Fragment?
For example, in this ListFragment I need to retrieve an array of things to display to the user. The things I'm displaying need to be retrieved dynamically and added to a custom adapter. It currently looks as follows:
public class MyFragment extends ListFragment {
private List<ListItem> mList;
void setListValues(List<ListItem> values) {
this.mList = values;
}
List<ListItem> getListValues() {
return this.mList;
}
#Override
public void onCreateView(LayoutInflater i, ViewGroup vg, Bundle b) {
// blah blah blah
}
#Override
public void onViewCreated(View view, Bundle savedInstanceState) {
this.setListValues(ListFactory.getListOfDynamicValues());
CustomAdapter adapter = new CustomAdapter(
getActivity(),
R.layout.row_layout,
this.getListValues());
this.setListAdapter(adapter);
}
}
I'm trying to do this using Mockito and Robolectric.
This is the beginning of my robolectric test case:
public class MyFragmentTest {
private MyFragment fragment;
#Before
public void setup() {
ListItem item1 = mock(ListItem.class);
ListItem item2 = mock(ListItem.class);
when(item1.getValue()).thenReturn("known value 1");
when(item2.getValue()).thenReturn("known value 2");
List<ListItem> mockList = new ArrayList<ListItem>();
mockList.add(item1);
mockList.add(item2);
MyFragment real = new MyFragment();
this.fragment = spy(real);
when(this.fragment.getValueList()).thenReturn(mockList);
startFragment();
}
}
This feels so very wrong. This section from the mockito api points out that you shouldn't have to do partial mocks like this very frequently unless you're dealing with legacy code.
Further, I'm not actually able to mock out the CustomAdapter class using this approach.
What is the right way to do this sort of thing? Am I structuring things incorrectly in my Fragment classes? I suppose I might be able to add a bunch of package-private setters, but this still doesn't feel right.
Can someone shed some light on this? I'm happy to do rewrites, I just want to know some good patterns for dealing with the state in my Fragments and how I can make them testable.
I ended up creating my own solution to this. My approach was to add another level of indirection to each my calls that create or set an object.
First, let me point out that I couldn't actually get Mockito to work reliably with Fragment or Activity objects. It was somewhat hit or miss, but especially with trying to create Mockito Spy objects, some lifecycle methods appeared to not be called. I think this is related to gotcha number 2 shown here. Perhaps this is due to the ways that Android uses reflection to recreate and instantiate activities and fragments? Note that I was NOT incorrectly holding onto the reference, as it warns of, but interacting only with the Spy, as indicated.
So, I wasn't able to mock Android objects that required lifecycle methods be invoked by the framework.
My solution was to create to more types of methods in my Activity and Fragment methods. These methods are:
getters (getX()) that return the field named X.
retrievers (retrieveX()) that do some sort of work to get an object.
creators (createMyFragment()) that create objects by calling new. Similar to the retrievers.
Getters have whatever visibility you need. Mine are usually public or private.
Retrievers and creators are package private or protected, allowing you to override them in your test packages but not making them generally available. The idea behind these methods is that you can subclass your regular objects with stub objects and inject in known values during testing. You could also just mock out those methods if Mockito mocks/spies are working for you.
Taken in toto, the test would look something like the following.
Here is the fragment from my original question, modified to use the above approach. This is in the normal project:
package org.myexample.fragments
// imports
public class MyFragment extends ListFragment {
private List<ListItem> mList;
void setListValues(List<ListItem> values) {
this.mList = values;
}
List<ListItem> getListValues() {
return this.mList;
}
#Override
public void onCreateView(LayoutInflater i, ViewGroup vg, Bundle b) {
// blah blah blah
}
#Override
public void onViewCreated(View view, Bundle savedInstanceState) {
this.setListValues(this.retrieveListItems());
CustomAdapter adapter = this.createCustomAdapter();
this.setListAdapter(adapter);
}
List<ListItem> retrieveListItems() {
List<Item> result = ListFactory.getListOfDynamicValues();
return result;
}
CustomAdapter createCustomAdapter() {
CustomAdapter result = new CustomAdapter(
this.getActivity();
R.layout.row_layout,
this.getListValues());
return result;
}
}
When I test this object, I want to be able to control what gets passed around. My first thought was to use a Spy, replacing the return values of retrieveListItems() and createCustomAdapter() with my known values. However, like I said above, I wasn't able to get Mockito spies to behave when working with fragments. (Especially ListFragments--I had mixed success with other types, but don't trust it.) So, we are going to subclass this object. In the test project, I have the following. Note that your method visibility in your real class must allow subclasses to override, so it needs to be package private and in the same package or protected. Note that I am overriding the retriever and creator, returning instead static variables that my tests will set.
package org.myexample.fragments
// imports
public class MyFragmentStub extends MyFragment {
public static List<ListItem> LIST = null;
public static CustomAdapter ADAPTER = null;
/**
* Resets the state for the stub object. This should be called
* in the teardown methods of your test classes using this object.
*/
public static void resetState() {
LIST = null;
ADAPTER = null;
}
#Override
List<ListItem> retrieveListItems() {
return LIST_ITEMS;
}
#Override
CustomAdapter createCustomAdapter() {
return CUSTOM_ADAPTER;
}
}
In the same package in my test project I have the actual test of the fragment. Note that while I'm using Robolectric, this should work with whatever test framework you're using. The #Before annotation becomes less useful, as you need to update your static state for individual tests.
package org.myexample.fragments
// imports
#RunWith(RobolectricTestRunner.class)
public class MyFragmentTest {
public MyFragment fragment;
public Activity activity;
#After
public void after() {
// Very important to reset the state of the object under test,
// as otherwise your tests will affect each other.
MyFragmentStub.resetState();
}
private void setupState(List<ListItem> testList, CustomAdapter adapter) {
// Set the state you want the fragment to use.
MyFragmentStub.LIST = testList;
MyFragmentStub.ADAPTER = adapter;
MyFragmentStub stub = new MyFragmentStub();
// Start and attach the fragment using Robolectric.
// This method doesn't call visible() on the activity, though so
// you'll have to do that yourself.
FragmentTestUtil.startFragment(stub);
Robolectric.ActivityController.of(stub.getActivity()).visible();
this.fragment = stub;
this.activity = stub.getActivity();
}
#Test
public void dummyTestWithKnownValues() {
// This is a test that does nothing other than show you how to use
// the stub.
// Create whatever known values you want to test with.
List<ListItem> list = new ArrayList<ListItem>();
CustomAdapter adapter = mock(CustomAdapter.class);
this.setupState(list, adapter);
// android fest assertions
assertThat(this.fragment).isNotNull();
}
}
This is definitely more verbose than using a mocking framework. However, it works even with Android's life cycle. If I'm testing an Activity, I'll also often include a static boolean BUILD_FRAGMENTS variable. If true, I'll go call through to super in the appropriate methods or return a known fragment as appropriate. In this way I'm able to inject my test objects and play nice with the Android life cycle.
I'm working on a Android app which uses the Roboguice dependency injection framework.
So most of the time we extend RoboActivity, RoboListActivity and similar.
Now I would like to introduce some sort of global error handling which will show some alert or a error activity in case the application crashes.
I have done this before by implementing a base activity like this:
public class BaseActivity extends Activity
{
#Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
Thread.setDefaultUncaughtExceptionHandler(new GeneralError(this));
}
where I define the default exception handler and all other activities then derived from this one.
Now I'm wondering how this is achieved with Roboguice?
Here is some rough psuedo code that should get you started. It uses the roboguice events to make some of these cross cutting concerns a little easier.
public class GlobalErrorHandler {
// injects the current activity here
#Inject Context context;
public void onCreate(#Observes OnCreateEvent e) {
// Wires up the error handling
Thread.setDefaultUncaughtExceptionHandler(new GeneralError(context));
}
}
public class MySpecificActivity {
// required in every activity that needs error handling
#Inject GlobalErrorHandler errorHandler;
}
anyone could help me with the problem: how to test android apps which uses ormlite?
I'd like to know how to create mocks form dao. This code gets me a dao
public Dao<Account, Integer> getAccountDao() throws SQLException {
if (accountDao == null) {
accountDao = getDao(Account.class);
}
return accountDao;
}
My testing activity looks this:
public class OrmActivity extends OrmLiteBaseActivity<DatabaseHelper> {
/** Called when the activity is first created. */
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
initUi();
initUiListeners();
RuntimeExceptionDao<Account, Integer> accountDao = getHelper().getAccountDataDao();
Account account = new Account();
account.setName("name");
account.setPassword("password");
accountDao.create(account);
}
I dont want to create separate database for tests. Instend of it I want to use mocks.
Best regards
Just in case anyone else stumbles across this post. The issue I had was that you need an instance of an Activity so you can pass the context to the OpenHelperManager.getHelper(android.content.Context context, Class openHelperClass) method.
To get around this I create a ActivityInstrumentationTestCase2 test class to provide the context. You could use MockContext but I understand it to be problematic. This way is simple stupid, sort of :)
At that point I don't bother testing any of the Activity functionality, just database functionality.
public class TestActivity extends ActivityInstrumentationTestCase2<MainFragment> {
public TestActivity() {
super(MainFragment.class);
}
protected void setUp() throws Exception {
super.setUp();
//DatabaseHelper.class is the extended OrmLiteSqliteOpenHelper class
OpenHelperManager.getHelper(getActivity(), DatabaseHelper.class);
}
protected void tearDown() throws Exception {
OpenHelperManager.releaseHelper();
super.tearDown();
}
public void testDetailDiscount() {
//Example code using an entity class that encapsulates ormlite functionality
double total = 95 * 5;
DocumentDetail detail = DocumentDetail.create(getActivity());
assertEquals(total, detail.getTotal());
}
}
Hope it helps
I use Robolectric for unit testing Android apps. Works fine with RoboGuice and Ormlite. Robolectric creates its own database, so a unit test doesn't modify the database on the device you are testing with.
If this doesn't answer your question, please clarify your question. Like, how is not using a separate database related to using mock dao's?
Is there any way in android to intercept activity method calls (just the standart ones, like "onStart. onCreate")?
I have a lot of functionality that must be present in every activity in my app, and (since it uses different types of activities (List, Preferences)) the only way to do it is to create my custom extensions for every activity class, which sucks :(
P.S. I use roboguice, but since Dalvik doesn't support code generation at runtime, I guess it doesn't help much.
P.S.S. I thought about using AspectJ, but it's too much of a hassle since it requires a lot of complications (ant's build.xml and all that junk)
The roboguice 1.1.1 release includes some basic event support for components injected into a context. See http://code.google.com/p/roboguice/wiki/Events for more info.
For Example:
#ContextScoped
public class MyObserver {
void handleOnCreate(#Observes OnCreatedEvent e) {
Log.i("MyTag", "onCreated");
}
}
public class MyActivity extends RoboActivity {
#Inject MyObserver observer; // injecting the component here will cause auto-wiring of the handleOnCreate method in the component.
protected void onCreate(Bundle state) {
super.onCreate(state); /* observer.handleOnCreate() will be invoked here */
}
}
You could delegate all the repetitive work to another class that would be embedded in your other activities. This way you limit the repetitive work to creating this object and calling its onCreate, onDestroy methods.
class MyActivityDelegate {
MyActivityDelegate(Activity a) {}
public void onCreate(Bundle savedInstanceState) {}
public void onDestroy() {}
}
class MyActivity extends ListActivity {
MyActivityDelegate commonStuff;
public MyActivity() {
commonStuff = MyActivityDelegate(this);
}
public onCreate(Bundle savedInstanceState) {
commonStuff.onCreate(savedInstanceState);
// ...
}
}
This minimalises the hassle and factorises all common methods and members of your activities. The other way to do it is to subclasse all the API's XXXActivty classes :(
Take a look at http://code.google.com/p/android-method-interceptor/, it uses Java Proxies.