Home » Android » android – What does testAndroidTestCaseSetUpProperly do

android – What does testAndroidTestCaseSetUpProperly do

Posted by: admin June 15, 2020 Leave a comment

Questions:

I know that in Android, the extra test testAndroidTestCaseSetUpProperly is often added to test cases (not sure whether it happens all the time). I’ve never needed to give it much though before, but whilst analysing some tests which use a ContentProvider I noticed something strange.

When I added the following logging in my ContentProvider:

static
{
    Log.d("UKMPG", "Initialising URIMatcher");
    uriMatcher = new UriMatcher(UriMatcher.NO_MATCH);
    //add uris
}

    @Override
public boolean onCreate()
{
    Log.d("UKMPG", "onCreate() called in ContentProvider");
    //set up db
}

I notice that these logs appear twice in logcat (blank lines added by me):

    12-31 13:00:07.112: D/AndroidRuntime(1135): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
12-31 13:00:07.112: D/AndroidRuntime(1135): CheckJNI is ON
12-31 13:00:07.333: D/AndroidRuntime(1135): --- registering native functions ---
12-31 13:00:07.342: I/jdwp(1135): received file descriptor 21 from ADB
12-31 13:00:07.592: D/ddm-heap(1135): Got feature list request
12-31 13:00:08.072: D/ActivityManager(52): Uninstalling process com.fastplanet.ukmpgtracker
12-31 13:00:08.112: I/ActivityManager(52): Start proc com.fastplanet.ukmpgtracker for added application com.fastplanet.ukmpgtracker: pid=1142 uid=10028 gids={1015}
12-31 13:00:08.162: I/jdwp(1142): received file descriptor 10 from ADB
12-31 13:00:08.222: D/ddm-heap(1142): Got feature list request
12-31 13:00:08.502: I/TestRunner(1142): started: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)
12-31 13:00:08.512: I/ActivityThread(1142): Publishing provider com.fastplanet.ukmpgtracker.data.UKMPG: com.fastplanet.ukmpgtracker.data.UKMPGContentProvider

12-31 13:00:08.512: D/UKMPG(1142): Initialising URIMatcher
12-31 13:00:08.522: D/UKMPG(1142): onCreate() called in ContentProvider

12-31 13:00:08.552: I/TestRunner(1142): finished: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)
12-31 13:00:08.552: I/TestRunner(1142): passed: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)
12-31 13:00:08.582: D/ActivityManager(52): Uninstalling process com.fastplanet.ukmpgtracker
12-31 13:00:08.582: D/ActivityManager(52): Force removing process ProcessRecord{43879630 1142:com.fastplanet.ukmpgtracker/10028} (com.fastplanet.ukmpgtracker/10028)
12-31 13:00:08.582: I/Process(52): Sending signal. PID: 1142 SIG: 9
12-31 13:00:08.602: D/ActivityManager(52): Received spurious death notification for thread [email protected]
12-31 13:00:08.612: D/AndroidRuntime(1135): Shutting down VM
12-31 13:00:08.612: D/dalvikvm(1135): DestroyJavaVM waiting for non-daemon threads to exit
12-31 13:00:08.622: D/dalvikvm(1135): DestroyJavaVM shutting VM down
12-31 13:00:08.622: D/dalvikvm(1135): HeapWorker thread shutting down
12-31 13:00:08.622: D/dalvikvm(1135): HeapWorker thread has shut down
12-31 13:00:08.622: D/jdwp(1135): JDWP shutting down net...
12-31 13:00:08.622: D/jdwp(1135): Got wake-up signal, bailing out of select
12-31 13:00:08.622: I/dalvikvm(1135): Debugger has detached; object registry had 1 entries
12-31 13:00:08.632: D/dalvikvm(1135): VM cleaning up
12-31 13:00:08.642: D/dalvikvm(1135): LinearAlloc 0x0 used 684532 of 4194304 (16%)
12-31 13:00:09.042: D/AndroidRuntime(1155): >>>>>>>>>>>>>> AndroidRuntime START <<<<<<<<<<<<<<
12-31 13:00:09.042: D/AndroidRuntime(1155): CheckJNI is ON
12-31 13:00:09.272: D/AndroidRuntime(1155): --- registering native functions ---
12-31 13:00:09.282: I/jdwp(1155): received file descriptor 21 from ADB
12-31 13:00:09.552: D/ddm-heap(1155): Got feature list request
12-31 13:00:10.062: D/ActivityManager(52): Uninstalling process com.fastplanet.ukmpgtracker
12-31 13:00:10.082: I/ActivityManager(52): Start proc com.fastplanet.ukmpgtracker for added application com.fastplanet.ukmpgtracker: pid=1162 uid=10028 gids={1015}
12-31 13:00:10.133: I/jdwp(1162): received file descriptor 10 from ADB
12-31 13:00:10.172: D/ddm-heap(1162): Got feature list request
12-31 13:00:10.472: I/TestRunner(1162): started: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)


12-31 13:00:10.512: D/UKMPG(1162): Initialising URIMatcher
12-31 13:00:10.512: D/ActivityThread(1162): Loading provider com.fastplanet.ukmpgtracker.data.UKMPG: com.fastplanet.ukmpgtracker.data.UKMPGContentProvider
12-31 13:00:10.522: D/UKMPG(1162): onCreate() called in ContentProvider


12-31 13:00:10.532: I/ActivityThread(1162): Publishing provider com.fastplanet.ukmpgtracker.data.UKMPG: com.fastplanet.ukmpgtracker.data.UKMPGContentProvider
12-31 13:00:10.532: D/UKMPG(1162): onCreate() called in ContentProvider
12-31 13:00:10.812: I/TestRunner(1162): finished: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)
12-31 13:00:10.822: I/TestRunner(1162): passed: testAddNewVehicle(com.fastplanet.ukmpgtracker.test.VehicleProviderTest)
12-31 13:00:10.842: D/ActivityManager(52): Uninstalling process com.fastplanet.ukmpgtracker
12-31 13:00:10.852: D/ActivityManager(52): Force removing process ProcessRecord{4395a680 1162:com.fastplanet.ukmpgtracker/10028} (com.fastplanet.ukmpgtracker/10028)
12-31 13:00:10.852: I/Process(52): Sending signal. PID: 1162 SIG: 9
12-31 13:00:10.872: D/ActivityManager(52): Received spurious death notification for thread [email protected]
12-31 13:00:10.872: D/AndroidRuntime(1155): Shutting down VM
12-31 13:00:10.872: D/dalvikvm(1155): DestroyJavaVM waiting for non-daemon threads to exit
12-31 13:00:10.882: D/dalvikvm(1155): DestroyJavaVM shutting VM down
12-31 13:00:10.882: D/dalvikvm(1155): HeapWorker thread shutting down
12-31 13:00:10.892: D/dalvikvm(1155): HeapWorker thread has shut down
12-31 13:00:10.892: D/jdwp(1155): JDWP shutting down net...
12-31 13:00:10.892: D/jdwp(1155): Got wake-up signal, bailing out of select
12-31 13:00:10.892: I/dalvikvm(1155): Debugger has detached; object registry had 1 entries
12-31 13:00:10.892: D/dalvikvm(1155): VM cleaning up
12-31 13:00:10.912: D/dalvikvm(1155): LinearAlloc 0x0 used 684532 of 4194304 (16%)

The first time they are logged, the application column is blank, but the second time my top level package appears.

Any ideas what this extra test does?

How to&Answers:

It asserts that the context field in a TestCase is not null.

//In android.test.AndroidTestCase class
public void testAndroidTestCaseSetupProperly() {
    assertNotNull("Context is null. setContext should be called before tests are run", mContext);        
}

Answer:

As @user1154664 said, also in the source code here at line 44 :

public void testAndroidTestCaseSetupProperly() {
    assertNotNull("Context is null. setContext should be called before tests are run",
            mContext);        
}

And trace back mContext is protected (line 32):

protected Context mContext;

which means it could be modified by subclasses. And it can also be modified by the setter method:

public void setContext(Context context) {
    mContext = context;
}

In short, it is no different to public (totally exposed!).

If you want to play with testAndroidTestCaseSetupProperly(), you could set it to null in your setUp():

@Override
protected void setUp() throws Exception {
    super.setUp();
    setContext(null);
}

So this will make testAndroidTestCaseSetupProperly fails. (-:

Ok. Be serious. The testAndroidTestCaseSetupProperly test case is sitting there as a safeguard of the rest of the test cases to be meaningful, just like what testPreconditions() does.

As this is the AndroidTestCase which focus on access Resources or other things that depend on Activity Context (as the source codes says, line 28), the context should be generally critical among most of the test cases. Putting it there as a precondition is more than reasonable.

So, where does the context come from? It is roughly from the TestRunner (line 339) -> AndroidTestRunner (line 162->170).

Answer:

Unfortunately, it’s not documented at all. It looks to me like it is an extra test case that is testing that your setUp() and tearDown() methods are working on their own.