Unidad de prueba de servicios de dominio contra una base de datos real

Question

Me preguntaba qué enfoques podrían tener otros para probar los servicios de dominio en una base de datos. Ya tengo una serie de repositorios simulados que puedo usar en los servicios de dominio para probar los servicios de dominio. Parte de la construcción de estos repositorios simulados es que construyen agregados de muestra y entidades asociadas y los validan contra las mismas reglas comerciales que de otro modo se usarían dentro del modelo. Esto también proporciona un medio agradable y simple para detectar posibles puntos de impacto dentro de las propias entidades, en caso de que cambien sus interfaces.

El principal problema que veo con las pruebas en vivo de mis repositorios respaldados por SQL es la consistencia de la base de datos. Por ejemplo, una vez que se ejecuta una prueba, " crear " aspectos ya han sido ejecutados. Ejecutarlos nuevamente obviamente causaría fallas, ya que la base de datos ya no es impecable. Estaba considerando crear una base de datos reflejada utilizada solo para este tipo de pruebas. Sería mínimo, con estructura, programabilidad, restricciones, etc. También proporcionaría un conjunto mínimo de datos para ciertas pruebas establecidas. Mi línea de pensamiento es que podría tener un procedimiento almacenado al que podría llamar para restablecer la base de datos a "impecable" estado con datos base antes del inicio de la ejecución de prueba.

Si bien esto no es tan importante en una máquina de desarrollador después de que se haya verificado inicialmente la funcionalidad, estoy estudiando más la importancia de ejecutar estas pruebas como parte de la compilación nocturna; de modo que, en caso de falla de la prueba, la compilación podría retrasarse para no dañar el entorno de implementación objetivo (específicamente en este caso, sería el entorno que utiliza el equipo de prueba).

No creo necesariamente que la plataforma sea importante, pero en caso de que alguien tenga problemas específicos de implementación, mi entorno tiene el siguiente aspecto:

Windows 7 (Desarrollo) / Windows Server 2008 R2 (Servidor) Visual Studio 2008 Team Edition (C #) Microsoft SQL Server 2008 Standard (Desarrollo / Servidor)

Estoy usando Team Build para ejecutar mis compilaciones, pero lo más probable es que no sea un factor en el alcance de la pregunta.

Answer 1

  

Por ejemplo, una vez que se ejecuta una prueba, " crear " aspectos ya han sido ejecutados. Ejecutarlos nuevamente obviamente causaría fallas, ya que la base de datos ya no es impecable.

Tal vez podrías hacer que tus pruebas unitarias sean transaccionales. Ejecute sus pruebas, regréselas y la base de datos no cambiará.

Spring tiene clases de prueba de unidad transaccional que facilitan esta tarea. Solo necesita un administrador de transacciones.

Answer 2

Puede usar SQL Server Express (I ' Lo he hecho con 2005, pero no he intentado con 2008) para configurar " plataforma de prueba " bases de datos que se almacenan como archivos. Estos pueden registrarse en el control de origen, luego las clases auxiliares de prueba pueden (a) copiarlos en carpetas temporales, (b) habilitarlos para escritura y (c) conectarse a ellos. Para restaurar el estado original, elimine la copia temporal y repita a-c.

Este es un gran dolor. Si puedes salir adelante con las transacciones (como sugirió duffymo) Yo iría con eso. Los puntos débiles con las transacciones son transacciones anidadas y distribuidas: tenga cuidado con las de su código.

Answer 3

Puede crear un montón de fábricas de datos en el código de prueba que inicialmente se ejecutan al inicio de su ejecución de prueba. Luego use el método de reversión de transacciones para mantenerlo impecable. Para hacerlo más fácil, subclasifique todas sus clases de prueba y coloque el código de acceso de transacción y reversión allí. El código de reversión se puede configurar para que se ejecute automáticamente al finalizar cada método de prueba.

Answer 4

si en realidad está ejecutando pruebas unitarias para su repositorio que están llegando a una base de datos, NO ESTÁ HACIENDO PRUEBAS DE UNIDAD. Puede ser una prueba útil pero no es una prueba unitaria. Esa es una prueba de integración. Si desea hacer eso y llamarlo una prueba de integración, entonces está perfectamente bien. Sin embargo, si sigue buenos principios de diseño en sus repositorios, entonces no necesita probar la base de datos, NUNCA, en sus pruebas unitarias.

En pocas palabras, su prueba de unidad de repositorio NO es para probar qué efectos amplios ocurren en la base de datos en función de la entrada al repositorio; es para confirmar que la entrada al repositorio resulta en una llamada a un colaborador con tal y tal conjunto de valores.

Verá, el repositorio, como el resto de su código, debe seguir el Principio de Reposibilidad Única. Básicamente, su repositorio tiene UNA y SOLO UNA reposibilidad y eso es para mediar las preocupaciones de la API del modelo de dominio en la capa de tecnología de acceso a datos subyacente (generalmente ADO.Net pero podría ser Entity Framework o L2S o lo que sea). Siguiendo con el ejemplo de las llamadas ADO.Net, su repositorio no debería asumir la responsabilidad de ser una fábrica para la capa de datos y, en cambio, debería depender de un colaborador de las interfaces de datos ADO.Net (específicamente IDbConnection / IDbCommand / IDbParameter etc) Simplemente tome un IDbConnection como parámetro constructor y llámelo un día. Esto significa que puede escribir pruebas unitarias de repositorio contra las interfaces y simulacros de suministro (o falsificaciones o stubs o lo que necesite) y confirmar que se realizan los métodos necesarios, en orden, con las entradas esperadas. Visite mi blog de MS sobre este tema exacto: > http: // blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

Esperemos que esto le ayude a cometer un error en su prueba y diseño en el futuro.

Por cierto: si desea probar la unidad de la base de datos, puede hacerlo. Simplemente use las pruebas de base de datos de Visual Studio. Está construido INTO vs y ha existido desde VS2005. Esto no es nada nuevo. Pero necesito advertirle, deben ser pruebas de unidad completamente SEPARADAS.

Answer 5

Si su código es bastante independiente de la base de datos, el uso de una base de datos en memoria como SQLite para pruebas unitarias (no pruebas de integración) le brindará los beneficios de la velocidad y la facilidad (sus configuraciones de prueba inicializan el db).