Prueba de la clase de comunicación con DB a través de DAO de ORMLite
Estoy intentando adoptar un enfoque TDD al crear una aplicación para Android. Estoy usando ORMLite y Mockito / Robolectric para probar. Me he encontrado con problemas para probar una cosa sencilla:
(Método en alguna clase que envuelve las llamadas DAO)
- Proyecto de biblioteca de prueba autónoma no puede encontrar las clases de biblioteca
- Android JUnit4 Pruebas - ¿Dónde obtener el contexto de?
- Creación de un proyecto de prueba de Android en Eclipse
- No se pudieron determinar las dependencias para todas las tareas con robolectric gradle plugin
- Prueba de la unidad Android - Problemas de resolución y verificación
public List<ITask> getTasksForNextTwoWeeks() throws SQLException { // Code to be written }
Bueno, el código interior será sólo una llamada de método de consulta adecuada.
¿Cuál es el mejor método para probar ese código? He estado pensando en esto, pero no puedo pensar en la solución sin tener acceso a la base de datos real (ya sea real o una prueba).
Cualquier sugerencia bienvenida.
- ¿Cómo probar la clase usando resolver contenido / proveedor?
- Prueba JUnit con Robolectric: java.lang.InstantiationException
- Contexto de Android en pruebas de unidades que no son de actividad
- Prueba de Android Realm con RxJava - "abierto desde un hilo sin un Looper" Excepción
- Fragmento getActivity () devuelve null en la actividad JUnit test
- Actualizar Robolectric 2.4: Obtener error de etiqueta de aplicación para proyectos de biblioteca en eclipse
- Obtener resultado de una actividad después de terminar (); En una prueba de unidad de Android
- Cómo proporcionar archivos de datos para las pruebas de unidad de Android
Hrm. Depende un poco de cómo está creando su clase Dao. Bajo ORMLite , la clase Dao es una interfaz que significa que con un poco de cableado, debe ser capaz de inyectar un DAO burlado y sólo manejar las llamadas de consulta a través de la simulación.
Por ejemplo, podría tener un método setDao
en su clase de envoltura sorta como esto:
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; }
Entonces su 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 burla para obtener el QueryBuilder
.
Lo que hacemos es extender la interfaz ORMLIte Dao
y añadir 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 el ITaskDao
y omitir todas las operaciones de base de datos.
Espero que esto ayude.
No soy fan de la respuesta de Gray, ya que hace las cosas un poco demasiado complicadas. Le recomiendo simplemente crear en la memoria de la base de datos en su lugar, pasando null como un nombre de base de datos:
OrmLiteSqliteOpenHelper(context,null, null, DATABASE_VERSION );
De esta manera puede probar sus consultas en una sola prueba mediante a) añadir elementos simulados b) probar si su SqliteOpenHelper
-wrapper devuelve resultados correctos
Cada prueba como esa es completamente independiente de su base de datos actual y otras pruebas en su suite.
- ¿Cómo llevar una Actividad al primer plano (o crear si no existe)?
- Validar cadena con regex en android