¿Dónde debo trazar la línea entre las pruebas unitarias y las pruebas de integración? ¿Deberían estar separados?

Tengo un pequeño marco MVC en el que he estado trabajando. Su base de código definitivamente no es grande, pero ya no es solo un par de clases. Finalmente decidí dar el paso y comenzar a escribir pruebas para ello (sí, sé que debería haber estado haciendo eso todo el tiempo, pero su API era súper inestable hasta ahora)

De todos modos, mi plan es hacer que la prueba sea extremadamente fácil, incluidas las pruebas de integración. Un ejemplo de prueba de integración iría en este sentido:

Objeto de solicitud HTTP falso -> Marco MVC -> Objeto de respuesta HTTP -> verifique que la respuesta sea correcta

Debido a que todo esto es factible sin ningún estado o herramientas especiales (automatización del navegador, etc.), en realidad podría hacerlo con facilidad con los marcos de prueba de unidad regulares (uso NUnit).

Ahora la gran pregunta. ¿Dónde exactamente debo trazar la línea entre las pruebas unitarias y las pruebas de integración? ¿Debería probar solo una clase a la vez (tanto como sea posible) con pruebas unitarias? Además, ¿deberían colocarse las pruebas de integración en el mismo proyecto de prueba que mi proyecto de prueba de unidad?

Integración versus pruebas unitarias

Debe mantener sus pruebas unitarias y sus pruebas de integración completamente separadas. Las pruebas unitarias deben probar una cosa y una sola y en completo aislamiento del resto de su sistema. Una unidad está poco definida pero generalmente se reduce a un método o una función.

Tiene sentido tener pruebas para cada unidad para que sepa que sus algoritmos se implementan correctamente e inmediatamente sabe qué salió mal dónde, si la implementación es defectuosa.

Dado que realiza pruebas en aislamiento completo mientras realiza pruebas unitarias, utiliza objetos de prueba y simulados para comportarse como el resto de su aplicación. Aquí es donde entran las pruebas de integración. Probar todas las unidades de forma aislada es excelente, pero es necesario saber si las unidades realmente funcionan juntas.

Esto significa saber si un modelo está realmente almacenado en una base de datos o si realmente se emite una advertencia después de que el algoritmo X falla.

Desarrollo dirigido por pruebas

Dando un paso atrás y observando el Desarrollo impulsado por pruebas (TDD), hay varias cosas a tener en cuenta.

1. Escribe la prueba de la unidad antes de escribir el código que la hace pasar.
2. Hace pasar la prueba, escribe el código suficiente para lograr esto.
3. Ahora que la prueba pasa, es hora de dar un paso atrás. ¿Hay algo para refactorizar con esta nueva funcionalidad? Puede hacerlo de forma segura ya que todo está cubierto por pruebas.

Integración primero vs Integración último

Las pruebas de integración se ajustan a este ciclo TDD de una de dos maneras. Sé de personas que les gusta escribir de antemano. Llaman a una prueba de integración una prueba de extremo a extremo y definen una prueba de extremo a extremo como una prueba que prueba completamente la ruta completa de un caso de uso (piense en configurar una aplicación, arrancarla, ir a un controlador, ejecutarla, comprobando el resultado, salida, etc ...). Luego comienzan con su primera prueba de unidad, la aprueban, agregan una segunda, la aprueban, etc. Lentamente, más y más partes de la prueba de integración pasan también hasta que la función finaliza.

El otro estilo es construir una prueba de unidad de característica por prueba de unidad y agregar las pruebas de integración que se consideren necesarias después. La gran diferencia entre estos dos es que, en el caso de la prueba de integración, primero se ve obligado a pensar en el diseño de una aplicación. Esto no está de acuerdo con la premisa de que TDD se trata tanto del diseño de la aplicación como de las pruebas.

Practicidades

En mi trabajo tenemos todas nuestras pruebas en el mismo proyecto. Sin embargo, hay diferentes grupos. La herramienta de integración continua ejecuta primero lo que se marca como pruebas unitarias. Solo si estos tienen éxito, también se ejecutan las pruebas de integración más lentas (porque hacen solicitudes reales, usan bases de datos reales, etc.).

Por lo general, usamos un archivo de prueba para una clase por cierto.

Lectura sugerida

1. Creciente software orientado a objetos, guiado por pruebas Este libro es un muy buen ejemplo de la primera metodología de prueba de integración
2. El arte de las pruebas unitarias, con ejemplos en dot.net En pruebas unitarias, con ejemplos en dot.net: D Muy buen libro sobre los principios detrás de las pruebas unitarias.
3. Robert C. Martin en TDD (artículos gratuitos): Lea también los dos primeros artículos que vinculó allí.

Lo que es importante en cualquier estrategia de prueba es la cobertura de prueba, es decir, poder demostrar que se está probando toda la funcionalidad.

En general, y a menos que tenga requisitos específicos en contrario (por ejemplo, DO178 Nivel A, IEC61508 SIL 4, etc.) que no parece ser el caso en su situación, entonces si puede probar la función completa de la clase o un módulo (y demuestre que tiene) a nivel de sistema, entonces las pruebas a nivel de sistema son adecuadas. Y así sucesivamente. Las pruebas unitarias solo son necesarias cuando no ha cubierto las pruebas más arriba.

¿Dónde exactamente debo trazar la línea entre las pruebas unitarias y las pruebas de integración?

Dado que las pruebas de integración suelen ser más fáciles, más rápidas y más baratas, dibuje la línea lo más lejos posible ...

¿Debería probar solo una clase a la vez (tanto como sea posible) con pruebas unitarias?

Depende del alcance, de nuevo ... por definición, una prueba unitaria está probando una sola unidad. Pero si puede probar completamente un módulo completo de una vez, entonces si lo desea, hágalo. En efecto, estás cumpliendo varias pruebas unitarias en un solo golpe.

Además, ¿deberían colocarse las pruebas de integración en el mismo proyecto de prueba que mi proyecto de prueba de unidad?

No hay una razón fundamental por la que no ... a menos que la prueba de nivel superior sea realizada por un probador independiente, en cuyo punto solo debe emitir una instrumentación ejecutable y mínima.

Cuando tengo proyectos pequeños, solo hago estallar todas las pruebas en el mismo proyecto. Como un proyecto más grande tendría estas divisiones, solo me aseguro de que sería posible separarlas si fuera necesario.

Con las pruebas unitarias, normalmente solo pruebo una clase (SUT) en un archivo.