2012-07-03 12 views
19

Una de las cosas que me gusta de Rails' y Django's es que su enfoque de prueba es utilizar dispositivos para configurar una base de datos antes de ejecutar cada prueba.Entity Framework de prueba con dispositivos

En el pasado, he usado pruebas unitarias estrictas junto con un repositorio simulado para probar mi código, pero me gustaría tener algo tan fácil de usar como los enfoques de prueba antes mencionados para hacer pruebas integradas .

He escuchado hablar de este tipo de soporte con código primero y EF 5, pero no sé si se eleva al nivel de lo que ofrecen Rails y Django.

Seguramente hay algo comparable. ¡Cualquier información sería apreciada!

+0

Solo sabía que @LadislavMnrka estaría en todo esto. :) –

+0

Creo que [AutoFixture] (https://github.com/AutoFixture/AutoFixture) está lejos de ser la solución que está buscando, pero es lo más parecido que puedo encontrar a la automatización de accesorios para EF. –

+0

no exactamente, EF permite la reinicialización de la base de datos (la crea nuevamente, posiblemente agrega datos, etc.), pero esto no está adjuntado a ningún marco de prueba, todo se hace cuando reinicia la aplicación en Visual Studio. Sin embargo, puede llamar a estos métodos de inicialización también desde su marco de prueba si desea –

Respuesta

12

En EF5 se ha introducido un nuevo concepto, llamado Migraciones. Probablemente solía usar algo similar en las aplicaciones Rails o Django.

La migración es una clase que tiene varias funciones para actualizar/reducir la versión de la base de datos.

public partial class VoteTime : DbMigration 
{ 
    public override void Up() 
    { 
     AddColumn("Votes", "Time", c => c.DateTime(nullable:false, defaultValue:DateTime.UtcNow)); 
    } 

    public override void Down() 
    { 
     DropColumn("Votes", "Time"); 
    } 
} 

También, tiene que configurar DbContext y clases de configuración DbMigrationsConfiguration a permitir que el código primer acercamiento al trabajo.

Para propósitos de prueba que necesita para introducir, TestDatabaseInitilizer

public class TestDatabaseInitilizer : DropCreateDatabaseAlways<DbContext> 
{ 

} 

Sería responsable de la inicialización de la base de datos de prueba para las pruebas unitarias.

Finalmente, debe diseñar su código de prueba para configurar el contexto.

public class SomeRepositoryTests 
{ 
    private DbContext _context; 

    [SetUp] 
    public void Setup() 
    { 
     Database.SetInitializer(new TestDatabaseInitilizer()); 
     _context = new DbContext("TestContext"); 
     _repository = new SomeRepository(_context); 
    } 

    [Test] 
    public void should_return_some_entities() 
    { 
     Assert.That(_repository.Get(), Is.Not.Null); 
    } 
} 

El código de configuración podría moverse a la clase base, si es necesario.

+0

Para bases de datos con muchas tablas y con un largo historial de migración, descartar la base de datos y recrearla para cada clase de prueba (o incluso método) puede agregar una gran sobrecarga a su tiempo de prueba. –

6

He desarrollado una aplicación con Entity Framework que tiene más de 600 pruebas de integración automática. Este es el proceso utilicé:

  • código de Entity Framework primeras migraciones sólo para establecer la estructura de base de datos (tablas, índices, etc.). No uso migraciones para generar datos.

  • Scripts SQL que configuran la base de datos en estados específicos y conocidos. Por ejemplo, una secuencia de comandos para insertar usuarios de membresía de ASP.NET; otro que establece datos de muestra para las tablas más relevantes; y otros para escenarios más específicos. Los scripts típicamente eliminan los registros de las tablas apropiadas y los insertan nuevamente, en el orden apropiado para evitar conflictos de relación. Los scripts se incluyen en el proyecto de Visual Studio como recursos integrados.

  • Clase de ayuda que puede obtener un script de los recursos por su nombre y ejecutarlo en la base de datos, incluidos los comandos de procesamiento por lotes con "IR". ConnectionContext.ExecuteNonQuery se puede usar para eso.

  • Al comienzo de todo el conjunto de pruebas, ejecuto el script que configura usuarios, permisos y otras configuraciones de entorno muy generales.

  • Antes de cada método de prueba, ejecuto uno o más scripts, según corresponda, para configurar la base de datos en el contexto requerido por las pruebas que se están ejecutando. Por ejemplo, antes de una serie de pruebas CRUD que leen, insertan, actualizan y eliminan datos, ejecuto un script que inicia la tabla apropiada con datos de prueba.

  • Escribo los casos de prueba suponiendo que la base de datos está configurada en un contexto específico. Por ejemplo, una prueba de una operación de actualización intentará recuperar un registro con una clave conocida, actualizarlo y volver a leer para verificar si se actualizó en la base de datos.

Aunque scripts SQL no son tan fáciles de escribir y leer como carriles de accesorios, son muy rápido y puede hacer cualquier tipo de manipulación es necesario (por ejemplo, DELETE, INSERT, UPDATE, ejecutar procedimientos almacenados).

Esta técnica fue bien probada en un proyecto que involucraba 50 tablas de bases de datos y reglas y procesos comerciales muy complejos. Mantuvo las pruebas simples y consistentes.

+0

Gracias por la experiencia – nXqd