2012-01-06 12 views
5

Estoy tratando de adoptar un enfoque TDD en la creación de la aplicación Android. Estoy usando ORMLite y Mockito/Robolectric para probar. Me he encontrado con problemas para probar una cosa simple:Clase de prueba que se comunica con DB a través del DAO de ORMLite

(método de alguna clase de envolver hasta DAO llama)

public List<ITask> getTasksForNextTwoWeeks() throws SQLException { 
    // Code to be written 
} 

Bueno, el código dentro será sólo una llamada adecuado método de consulta.

¿Cuál es el mejor enfoque para probar ese código? He estado pensando en esto, pero no puedo pensar en una solución sin acceder a la base de datos real (ya sea real o de prueba).

Cualquier sugerencia bienvenida.

+0

+1 para TDD, y el combo robolectric/mockito. –

Respuesta

2

Hrm. Depende un poco de cómo estás creando tu clase Dao. Debajo de ORMLite, la clase Dao es una interfaz que significa que con un poco de cableado, debería poder inyectar un DAO burlado y simplemente manejar las llamadas de consulta a través del simulacro.

Por ejemplo, usted podría tener un método setDao en su sorta clase de envoltura así:

public void setDao(Dao<ITask, String> dao) { 
    this.dao = dao; 
} 

private Dao<ITask, String> getDao() { 
    if (dao != null) { 
     // typical ORMLite pattern 
     dao = getHelper().getITaskDao(); 
    } 
    return dao; 
} 

A continuación, el método getTasksForNextTwoWeeks() haría algo como:

public List<ITask> getTasksForNextTwoWeeks() throws SQLException { 
    QueryBuilder<ITask, String> qb = getDao().getQueryBuilder(); 
    qb.where().gt(...); 
    return qb.query(); 
} 

Pero esto requiere un buen poco de burlarse de obtener el QueryBuilder.

Lo que hacemos es ampliar la interfaz ORMLIte Dao y agregar métodos como getTasksForNextTwoWeeks() a la clase ITaskDao.

public interface ITaskDao extends Dao<ITask, String> { 
    public List<ITask> getTasksForNextTwoWeeks() throws SQLException; 
    ... 
} 

A continuación, puede burlar fácilmente la ITaskDao y bypass todas las operaciones de bases de datos.

Espero que esto ayude.

+0

Ahora me pregunto si es mejor probar DAO como una unidad o realizar una prueba de integración con DB por adelantado. Burlarse de QueryBuilder parece una supercomplicación. – LordTwaroog

+0

De acuerdo. Recomiendo que la mayor parte de tu programa se burle del Dao como mencioné. Pero igual tendrá que probar la clase 'ITaskDao' también. – Gray

4

No soy seguidor de la respuesta de Gray, ya que hace las cosas un poco complicadas. Te recomiendo que simplemente crear la base de datos en memoria en su lugar, haciendo pasar null como un nombre de base de datos:

OrmLiteSqliteOpenHelper(context,null, null, DATABASE_VERSION); 

De esa manera usted puede probar sus consultas en una sola prueba por a) añadir elementos simulados b) prueba si su SqliteOpenHelper -wrapper arroja los resultados correctos

Todas las pruebas de este tipo son completamente independientes de su base de datos real y de otras pruebas en su suite.

Cuestiones relacionadas