testAndroidTestCaseSetUpProperly是做什么用的？

Question

testAndroidTestCaseSetUpProperly是做什么用的？

8

我知道在Android中，测试用例经常会添加额外的测试testAndroidTestCaseSetUpProperly（不确定是否总是这样）。我以前从未需要过多考虑它，但在分析一些使用ContentProvider的测试时，我注意到了一些奇怪的东西。

当我在我的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
}

我注意到这些日志在logcat中出现了两次（我添加了空行）：

    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 android.os.BinderProxy@4394fed0
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 android.os.BinderProxy@4395fe78
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%)

第一次登录时，应用程序列为空，但第二次出现我的顶级包。你有什么关于这个额外测试的想法吗？

- barry

3个回答

4

正如@user1154664所说，在这里的源代码的第44行：

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

并追溯回 mContext 是受保护的（第32行）：

protected Context mContext;

这意味着它可以被子类修改。它也可以通过setter方法进行修改：

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

简而言之，这与公开没有任何区别（完全暴露！）。

如果你想要与testAndroidTestCaseSetupProperly()一起玩耍，你可以在setUp()中将其设置为null:

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

所以这会导致testAndroidTestCaseSetupProperly失败。(-:

好的，请认真对待。 testAndroidTestCaseSetupProperly测试用例作为其余测试用例有意义的保护措施，就像testPreconditions()一样。

由于这是专注于访问资源或依赖Activity Context的AndroidTestCase（如源代码所示，第28行），因此context在大多数测试用例中通常至关重要。将其放置在那里作为前提条件是非常合理的。

那么，context来自哪里？它大致来自TestRunner（第339行） -> AndroidTestRunner（第162->170行）。

- midnite

1

很不幸，这一点都没有记录。在我看来，它似乎是一个额外的测试用例，用于测试setUp()和tearDown()方法是否能够独立工作。

- JonnyBoy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user1154664 · Accepted Answer

它声明了TestCase中的上下文字段不为空。

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