¿Se considera una "mala práctica" verificar el contenido / la codificación del archivo en las pruebas unitarias?

Lo más probable es que las pruebas que escribió estén más cerca de las pruebas de integración o de regresión que las pruebas unitarias. Si bien la línea puede ser muy borrosa y, a veces, se convierte en pedantería sobre lo que es o no es una prueba de unidad, me gustaría volver con su colega y preguntar dónde deberían estar las pruebas que escribió, ya que agregan un valor que garantiza la corrección del código. / p>

No me concentraría mucho en lo que es o no es una prueba de unidad y me doy cuenta de que incluso si es una prueba de integración, todavía podría haber valor en la prueba.

Técnicamente, no es una prueba de unidad, sino más bien un paso de validación. El enfoque adecuado realmente depende de lo que debe ser su flujo de trabajo. El líder de su equipo es correcto sobre cuál es el propósito de las pruebas unitarias. Mi sensación es que este es un caso de usar la herramienta incorrecta para un trabajo que aún debe hacerse. Así que empieza con esto:

  

¿Cuál es el problema que estoy tratando de resolver?

Según la descripción, debe validar que los scripts de la base de datos cumplan con algunos estándares.

  

¿Qué herramientas / procesos están disponibles para resolver el problema?

La calidad del código fuente generalmente se verifica mediante las herramientas análisis estático . Si no tiene una herramienta de análisis estático para validar su SQL, entonces puede crear una herramienta rápida y sucia que realice la comprobación en cualquier archivo de SQL que se le pase. No está mal comprobar si hay herramientas de análisis estático que puedan manejar los problemas de los que habla.

Si haces esa parte de tu infraestructura de compilación, como la incorporación a Jenkins o algo así, puede aplicarse a todos los archivos SQL de tu proyecto.

Las pruebas unitarias solo resuelven el problema de su archivo actual.

  

¿Cómo comunico la necesidad de la herramienta?

Esto es bastante fácil, hablas con el líder de tu equipo. Él puede trabajar con el propietario del producto y usted para determinar el riesgo / la recompensa de invertir en la herramienta. Si esto es probable que sea un problema único, entonces las herramientas probablemente sean excesivas. Si la herramienta para detectar los problemas más grandes es fácil, puede valer la pena solo por la comprobación de validez.

El líder de su equipo puede tener algunas ideas que usted (o yo) no hemos considerado, que pueden abordar el problema más correctamente.

Es una mala práctica llamar a las pruebas que acceden a los archivos "Pruebas unitarias".

  

Él: "Estas cosas no pertenecen a las pruebas unitarias"

     

Tú: "Tiene sentido, pero no pude encontrar un lugar mejor para colocarlos. ¿A dónde pertenecen?"

Lamentablemente, los tipos de pruebas que existen y la forma en que se organizan son totalmente específicos de la empresa. Por lo tanto, deberá averiguar cómo su empresa maneja estas pruebas.

Si aún no tiene una forma de ejecutar pruebas automáticas que no sean Pruebas Unitarias, el enfoque pragmático es marcar las Pruebas Unitarias que no son realmente Pruebas Unitarias con un prefijo, hasta que tenga suficientes de ellas para comenzar a averiguar Qué tipo de pruebas realmente tiene / necesita. Después de eso puedes empezar a organizar.

Michael Feathers dice esto en su libro Working Effectively With Legacy Code:

  

En la industria, las personas a menudo se preguntan si determinadas pruebas son pruebas unitarias. [...] Vuelvo a las dos cualidades: ¿La prueba se ejecuta rápidamente? ¿Puede ayudarnos a localizar errores rápidamente?

¿Su prueba ayudará a localizar errores rápidamente y se ejecutará más rápido? Si es así, entonces hazlo! Si no, entonces no! ¡Es tan simple como eso!

Dicho esto, estás trabajando en un entorno con otras personas y tienes que llevarte bien con ellas. Es posible que tenga que terminar haciéndolo a su manera, incluso si no está de acuerdo con él en privado.

He escrito pruebas similares, en ocasiones, contra archivos de código fuente, archivos de configuración, etc. No los llamaría pruebas unitarias porque (a) están accediendo al sistema de archivos y es posible que no sean ultra rápidos (b) No me importa si se ejecutan en cada registro (en lugar de cada noche en una Servidor CI).

Podrías llamarlos pruebas de integración; ciertamente, están más cerca de esa perspectiva que las pruebas unitarias.

Mi propio término para ellos es pruebas de recursos . En mi humilde opinión, se justifican por completo si se ejecutan todas las noches en un servidor de CI: el costo es mínimo y, cuando se utilizan con criterio, agregan claramente valor. Una definición de juiciosamente : si la prueba está comprobando un problema que causó un problema (como la codificación que menciona).

Una prueba de unidad consiste en probar un método o 'unidad' de código. Estás probando el grupo más pequeño de lógica y código en tu software.

Más adelante, cuando unas eso con otras unidades, realizarás pruebas de integración.

Espero que el líder de su equipo haya alentado su iniciativa y que haya ofrecido sugerencias alternativas. Definitivamente tienes la idea correcta.

Su SQL es un código como cualquier otro lenguaje de generación inferior como C # o Java y debe ser probado como tal. Y la verificación y validación pertenecen a todos los niveles de prueba. Por lo tanto, las declaraciones de codificación y SET se incluyen, pero no necesariamente se prueban exclusivamente. Por lo general, puede utilizar un enganche o función SCM.

La mejor práctica es realizar pruebas de regresión para asegurarse de que los errores pasados no se vuelvan a introducir. Generalmente, las pruebas se crean junto con cualquier resolución del error. Si estos errores no están cubiertos por pruebas de regresión a nivel de unidad / integración o sistema y luego se reintroducen, es un problema de equipo, un problema de proceso, no uno individual.

La cosa es ... los errores de sintaxis, las declaraciones faltantes o los bloques lógicos dentro de una 'unidad' no suelen probarse. Está probando las entradas y salidas de la unidad en diferentes combinaciones, probando las muchas posibilidades que podrían generarse.

Volviendo a las sentencias SET que faltan, ayudan a informar las muchas posibilidades de entrada y salida para probar. ¿Qué prueba escribirías que fallaría si te faltara algún SET elegido?

Si tiene archivos que se convierten en parte de su producto, entonces su contenido debe ser correcto. No hay razón por la que no verifiques esto. Por ejemplo, si necesita seis imágenes de 1024x 1024 en alguna carpeta, escriba una prueba unitaria que compruebe que tiene exactamente eso.

Pero probablemente no solo tienes los archivos, también tienes algo de código que los lee. Podrías escribir una prueba de unidad para ese código. En el ejemplo anterior, la función para leer una de las seis imágenes devuelve una imagen de 1024 x 1024 en la memoria (o lo que se suponía que debía producir).

De todos modos, puede que no sea una prueba de unidad, pero es una prueba útil. Y si usa un marco de prueba de unidad que le permite realizar una prueba útil (que no es una prueba de unidad), ¿por qué no usar el marco de prueba de unidad?

Quizás no entiendo bien su problema, pero para mí esto parece un problema que no debería ser capturado por ningún tipo de prueba dedicada, sino simplemente por el sistema de control de versiones . Cualquier cambio en una base de código debe revisarse parche por parche antes de confirmar. Una forma sencilla de hacer esto en git es agregar los cambios con

git add -p

Esto, para cada cambio en un archivo de texto, el directorio de trabajo le preguntará si realmente desea conservarlo. Eso le permitiría ver, por ejemplo, la eliminación de esas "declaraciones iniciales SET ".

En el caso de que la codificación de un archivo completo cambiara, algo diferente ocurriría: el algoritmo no podría diferenciar el archivo antiguo y el nuevo, y por lo tanto git add -p no agregaría nada. Esto sería visible en el otro comando que haría antes de cualquier confirmación, a saber,

git status

Aquí verías el archivo resaltado en rojo, lo que indica que hay cambios . Investigar por qué estos no llegaron a git add -p rápidamente haría que el problema sea obvio.

Otro ángulo a considerar: dado que esas dos condiciones son requisitos para que su programa se ejecute, ¿no debería incrustar la lógica cerca de la lógica de ejecución? Quiero decir: usted prueba la existencia de un archivo antes de leerlo y / o validar su contenido, ¿verdad? Entonces, ¿cómo es esto diferente? Creo que, dado que se trata de un recurso externo de código, debería validarse en tiempo de ejecución, antes de que realmente se utilice. Resultado: aplicación más fuerte, no es necesario escribir pruebas adicionales.

Las pruebas son el mismo código que cualquier otro y, si son lo suficientemente complejas, también se benefician de ... las pruebas unitarias. Parece más sencillo agregar dichas comprobaciones de condición previa directamente en la prueba.

La mayoría de las pruebas son lo suficientemente simples como para no requerir esto, pero si algunas son lo suficientemente complejas, no veo nada fundamentalmente incorrecto con estas comprobaciones de condición previa. Por supuesto, la prueba también debería fallar sin ellos, pero una buena prueba de unidad también le dice a qué unidad está fallando.

Un script que se usa como parte de la prueba y debe tener cierto contenido y codificación es probablemente una unidad. Puede tener mucho más código y lógica que el resto de la prueba. Una prueba con este tipo de script no es el mejor diseño y, si es posible, debe ser rediseñada en algo más directo (a menos que sea una prueba de integración).

En primer lugar, uno de los propósitos de las pruebas es evitar que se repitan problemas en su código, por lo que absolutamente debería seguir escribiendo pruebas de esta naturaleza.

En segundo lugar - nombrar es difícil. Sí, claramente no son "pruebas unitarias", pero pueden ser partes deseables y necesarias del proceso de compilación, porque lo protegen de errores obvios y porque le dan retroalimentación acerca de los errores antes (especialmente dado que no ve el consecuencias en una caja de desarrollo).

Entonces, la pregunta realmente es (debería estar en su contexto) más sobre cuándo y cómo se ejecutan estas pruebas que sobre lo que son.

He utilizado este tipo de prueba de forma extensiva en el pasado, nos han ahorrado una buena cantidad de dolor.

Las pruebas unitarias consisten en ejecutar una unidad de código aislada para confirmar que está produciendo el resultado correcto para la entrada correcta. El aislamiento debe hacer que tanto la unidad en prueba como la prueba sean repetibles, es decir, no deben depender de los efectos secundarios o introducirlos.

SQL no es exactamente algo que se pueda probar de forma aislada, por lo que cualquier prueba de SQL no es exactamente una prueba de unidad y, a excepción de las declaraciones SELECT, es casi seguro que tenga un efecto secundario. Podemos llamarlo una prueba de integración en lugar de una prueba de unidad.

Siempre es aconsejable asegurarse de que cualquier defecto que pueda introducirse pueda detectarse lo antes posible en el ciclo de desarrollo, y es beneficioso hacerlo de manera que sea fácil identificar la fuente del defecto para que Se puede corregir rápidamente.

Las pruebas en cuestión pueden reubicarse más adecuadamente fuera del cuerpo de "pruebas unitarias" y colocarse en otro lugar, pero no deben eliminarse por completo si están haciendo algo útil como protegerse contra la posible introducción de un defecto que podría tomar. horas para rastrear.