¿Es una buena práctica registrar simulacros de desarrollo utilizando la compilación condicional?

7

Estoy desarrollando una aplicación que se conecta a una base de datos, y estoy usando DI / IOC. Al ejecutar toda la aplicación mientras se desarrolla, naturalmente, quiero evitar golpear la base de datos. Actualmente, tengo algo como esto en mi raíz de composición (usando SimpleInjector):

#if DEBUG
    container.Register<IDbActions, MockDbActions>();
#else
    container.Register<IDbActions>(() => new RealDbActions(someParameter));
#endif

¿Es esta buena práctica o existe una mejor manera de registrar los simulacros utilizados para ejecutar toda la aplicación durante el desarrollo?

Editar: No se trata de pruebas de unidad. Todas las clases pueden probarse por unidad, independientemente de lo que esté en la raíz de la composición, porque el contenedor IOC nunca se usa durante la prueba unitaria (naturalmente).

    
pregunta cmeeren 20.02.2017 - 19:10

3 respuestas

7

No estoy de acuerdo con esta práctica.

  1. Si un probador de unidad está escribiendo una prueba y quiere burlarse de la base de datos de cierta manera, su código puede interferir con ese esfuerzo. Tendría que burlarse de tu burla.

  2. ¿Cómo prueba en unidad el código que no se compila en el modo de depuración (la instancia de RealDbActions )? En su ejemplo, la construcción es trivial, pero en algunos casos puede que no lo sea.

  3. No podrá ejecutar pruebas de integración automatizadas si el proyecto se compila en modo de depuración (la integración se simula). Si compilas en modo de lanzamiento, puede ser mucho más difícil analizar los resultados.

  4. Su base de código se contaminará con todos sus tipos de simulacros. Incluso si los excluye de la compilación, están en su árbol de origen y podrían afectar a diferencias, fusiones y otras actividades comunes siempre que las cambie.

  5. Si bien una clase delgada MockDbActions no puede ser tan mala, ¿qué sucede si tiene dependencias (por ejemplo, una biblioteca de burla)? ¿Vas a incluir referencias a esas en tu proyecto principal? ¿Se implementará en su centro de datos de producción? (Hasta donde sé, Visual Studio no admite directivas de compilación condicional para referencias).

respondido por el John Wu 21.02.2017 - 04:06
2

No estoy en desacuerdo con esta práctica en general, pero la usaría como último recurso. Como anécdota, utilicé esto al escribir aplicaciones que se conectan y leen hardware de sensores, pero no tenía hardware físico disponible, por lo que sin interrumpir la comunicación de hardware, la aplicación no habría podido ejecutarse como un todo.

Por lo tanto, si no tiene una base de datos para ejecutar en absoluto, puede usar esto en un apuro para poder ejecutar su aplicación, pero preferiblemente acceder a una base de datos de prueba y mantener las secuencias de comandos para restablecer sus datos de prueba a un estado conocido , si corresponde.

    
respondido por el patchandthat 21.02.2017 - 12:54
0

Como dijo @John Wu, la solución tiene el inconveniente de que combina código productivo y burlón.

Una opción para evitar esto podría ser mover el "Interruptor DED < > PROD" a la configuración. P.ej. para el marco de la entidad (primero el código), es fácil usar una base de datos ligera en la memoria en lugar de un dbms pesado. El archivo de configuración se puede configurar según la configuración de compilación (DEBUG / RELEASE).

Si eso no es posible y tiene alguna lógica de burla (más de una clase vacía), trataría de mover la lógica de burla en su propio ensamblaje para tener un límite claro.

Sin embargo, en su caso (con una clase vacía), solo agregaría un comentario en la parte superior del archivo y lo dejaría en el mismo proyecto ...;)

    
respondido por el JanDotNet 21.02.2017 - 11:53