Что делает testAndroidTestCaseSetUpProperly

Я знаю, что в 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%) 

При первом входе в систему столбец приложения пуст, но во второй раз появляется мой пакет верхнего уровня.

Любые идеи, что делает этот дополнительный тест?

Solutions Collecting From Web of "Что делает testAndroidTestCaseSetUpProperly"

Он утверждает, что поле контекста в TestCase не является нулевым.

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

Как сказал @ 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() , вы можете установить его значение null в свой setUp() :

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

Таким образом, это приведет к сбою testAndroidTestCaseSetupProperly . (-:

ОК. Будь серьезен. Экзамен testAndroidTestCaseSetupProperly сидит там как защита остальных тестовых случаев, чтобы иметь смысл, точно так же, как это делает testPreconditions() .

Поскольку это AndroidTestCase который фокусируется на доступе ресурсов или других вещах, которые зависят от контекста активности (как сказано в исходных текстах, строка 28), context должен быть в целом критическим для большинства тестовых случаев. Ввод его в качестве предварительного условия более чем разумно.

Итак, откуда возникает context ? Это примерно от TestRunner (строка 339) -> AndroidTestRunner (строка 162-> 170).

К сожалению, это вообще не документировано. Мне кажется, что это дополнительный тестовый пример, который проверяет, что ваши методы setUp () и tearDown () работают самостоятельно.