Tuve una discusión con un gerente de pruebas sobre el papel de las pruebas de unidad e integración. Ella solicitó que los desarrolladores informaran sobre qué han probado la unidad y la integración y cómo. Mi perspectiva es que las pruebas de unidad e integración son parte del proceso de desarrollo, no del proceso de prueba. Más allá de la semántica, lo que quiero decir es que las pruebas de unidad e integración no deben incluirse en los informes de prueba y los probadores de sistemas no deben preocuparse por ellas. Mi razonamiento se basa en dos cosas.
Las pruebas unitarias y de integración se planifican y realizan contra una interfaz y un contrato, siempre. Independientemente de si utiliza contratos formalizados, aún prueba lo que, por ejemplo, se supone que debe hacer un método, es decir, un contrato.
En las pruebas de integración, prueba la interfaz entre dos módulos distintos. La interfaz y el contrato determinan cuándo pasa la prueba. Pero siempre prueba una parte limitada de todo el sistema. Las pruebas de sistemas, por otro lado, se planifican y se realizan según las especificaciones del sistema. La especificación determina cuándo pasa la prueba.
No veo ningún valor en comunicar la amplitud y profundidad de las pruebas unitarias y de integración al probador (de sistemas). Supongamos que escribo un informe que enumera qué tipo de pruebas unitarias se realizan en una clase de capa empresarial particular. ¿Qué se supone que debe quitar de eso?
A juzgar por lo que debe y no debe probarse a partir de eso, es una conclusión falsa porque el sistema aún puede no funcionar de la manera que requieren las especificaciones a pesar de que pasan todas las pruebas de unidad e integración.
Esto puede parecer una discusión académica inútil, pero si trabajas en un ambiente estrictamente formal como yo, en realidad es importante para determinar cómo hacemos las cosas. De todos modos, ¿estoy totalmente equivocado?