Question

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?

Answer 1

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.