И ProviderTestCase, и RenamingDelegatingContext уничтожат базу данных, если она уже существует, прежде чем открыть ее в ее контексте, поэтому в этом смысле они оба имеют одинаковый подход низкого уровня к открытию базы данных SQLite.
Вы используете это, открыв базу данных в своем приборе в setUp(), после чего убедитесь, что вы работаете со свежей базой данных перед каждым тестовым случаем.
Я бы предположил, что вы идете писать контент-провайдеров, а не создавать адаптеры баз данных. Вы можете использовать общий интерфейс для доступа к данным, будь то в БД или где-то по сети, дизайн контент-провайдеров может быть адаптирован для доступа к таким данным за счет небольшого количества накладных IPC, что большинство из нас должно " t должны заботиться о.
Если вы сделали это для доступа к базе данных SQLite, инфраструктура полностью управляет соединением с базой данных для вас в отдельном процессе. В качестве добавленной говядины ProviderTestCase2<ContentProvider> полностью загружает тестовый контекст для вашего поставщика контента без необходимости писать одну строку кода.
Но, это не сказано, что это не такое огромное усилие, чтобы выполнить самонастраивание. Предположим, что у вас был адаптер базы данных; мы просто сосредоточиться на open() для получать доступ на запись в нашей базе данных, ничего фантазии:
public class MyAdapter {
private static final String DATABASE_NAME = "my.db";
private static final String DATABASE_TABLE = "table";
private static final int DATABASE_VERSION = 1;
/**
* Database queries
*/
private static final String DATABASE_CREATE_STATEMENT = "some awesome create statement";
private final Context mCtx;
private SQLiteDatabase mDb;
private DatabaseHelper mDbHelper;
private static class DatabaseHelper extends SQLiteOpenHelper {
public DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(DATABASE_CREATE_STATEMENT);
}
@Override
public void onUpgrade(SQLiteDatabase db, int a, int b) {
// here to enable this code to compile
}
}
/**
* Constructor - takes the provided context to allow for the database to be
* opened/created.
*
* @param context the Context within which to work.
*/
public MyAdapter(Context context) {
mCtx = context;
}
/**
* Open the last.fm database. If it cannot be opened, try to create a new
* instance of the database. If it cannot be created, throw an exception to
* signal the failure.
*
* @return this (self reference, allowing this to be chained in an
* initialization call)
* @throws SQLException if the database could be neither opened or created
*/
public MyAdapter open() throws SQLException {
mDbHelper = new DatabaseHelper(mCtx);
mDb = mDbHelper.getWritableDatabase();
return this;
}
public void close() {
mDbHelper.close();
}
}
Тогда вы могли бы написать тест, как например:
public final class MyAdapterTests extends AndroidTestCase {
private static final String TEST_FILE_PREFIX = "test_";
private MyAdapter mMyAdapter;
@Override
protected void setUp() throws Exception {
super.setUp();
RenamingDelegatingContext context
= new RenamingDelegatingContext(getContext(), TEST_FILE_PREFIX);
mMyAdapter = new MyAdapter(context);
mMyAdapter.open();
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
mMyAdapter.close();
mMyAdapter = null;
}
public void testPreConditions() {
assertNotNull(mMyAdapter);
}
}
Так что здесь происходит, что реализация контекста из RenamingDelegatingContext, как только MyAdapter(context).open() вызывается, всегда будет воссоздавать базу данных. Каждый тест, который вы сейчас пишете, будет противоречить состоянию базы данных после вызова MyAdapter.DATABASE_CREATE_STATEMENT.
[Проверка базы данных андроида в стиле JUnit4] (http://www.singhajit.com/testing-android-database/) –