I'm trying to test two different Activity
classes, where one Activity
happens to call the other. Here's my code and then I'll explain the problem:
IntroActivityTest
public class IntroActivityTest extends ActivityInstrumentationTestCase2<IntroActivity> {
IntroActivity activity;
public IntroActivityTest() {
super( IntroActivity.class );
}
@Override
protected void setUp() throws Exception {
super.setUp();
activity = getActivity();
}
public void testIntroBypass() {
if ( new SharedPreferencesHelper( getInstrumentation().getTargetContext() ).retrieveUserToken() == null ) {
assertTrue( !activity.isFinishing() );
}
else {
assertTrue( activity.isFinishing() );
}
}
}
RootActivityTest:
public class RootActivityTest extends ActivityInstrumentationTestCase2<RootActivity> {
RootActivity activity;
public RootActivityTest() {
super( RootActivity.class );
}
@Override
protected void setUp() throws Exception {
super.setUp();
activity = getActivity();
}
public void testInitialTab() {
assertTrue( activity.getSupportActionBar().getSelectedTab().getText().toString().equalsIgnoreCase( "Library" ) );
}
}
In IntroActivityTest
, if the user token from SharedPreferences
is non-null, it immediately starts RootActivity
. If it's null, it stays on IntroActivity
. The problem is that if it is non-null, the 1st test (IntroActivityTest
) passes, and then it hangs on the getActivity()
method call in RootActivityTest
and the test just freezes...no exceptions, it just hangs on that line. If the user token is null, it runs both tests completely fine.
What could be causing this? From observation, it appears that RootActivityTest
is trying to use the RootActivity
that was started from IntroActivity
, but shouldn't it be starting its own instance of RootActivity
?
According to the ActivityInstrumentationTestCase2 API:
This class provides functional testing of a single activity. The activity under test will be created using the system infrastructure (by calling InstrumentationTestCase.launchActivity()) and you will then be able to manipulate your Activity directly.
Each ActivityInstrumentationTestCase2 implementation is completely isolate and has its own life cycle which does not dependent on other ActivityInstrumentationTestCase2 implementation. A testable activity must be always created via instrumentation infrastructure, not from the application under test itself. In your case, RootActivityTest will not pick up RootActivity started by IntroActivity from application and continuous running test against RootActivity. If there is a RootActivity coming from no where (not by InstrumentationTestRunner) and is brought into front, when running RootActivityTest, InstrumentationTestRunner will get confused when try to create a testable RootActivity, and simply stop and waiting for this stranger to be killed.
To test what you want, i.e. if the user token from SharedPreferences is non-null, it immediately starts RootActivity. If it's null, it stays on IntroActivity, you can write everything in IntroActivityTest and use Instrumentation.ActivityMonitor detecting RootActivity started from IntroActivity. Check out here for code sample. note that you need finish RootActivity after done testing in IntroActivityTest so that RootActivity can start properly when calling getActivity() in RootActivityTest.
Use RootActivityTest for testing everything related to RootActivity after it has been started and brought to front, for example, TextView is well rendered, button click do the right thing and etc. In RootActivityTest, you don't need concern where and how RootActivity is started, just call getActivity() and ask instrumentation for a testable RootActivity.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With