¿Está bien evitar probar las clases base?

Tengo una clase base con una buena cantidad de "meta programación" para darle la flexibilidad / abstracción que necesita para ser bastante genérica.

Tengo muchas subclases que usan los métodos comunes en la clase base, y tengo pruebas unitarias orientadas al comportamiento que cubren todos los casos en cada subclase.

¿Está bien omitir probar la clase base?

unit-testing testing

— Nathan
fuente

Una cosa que a veces hago cuando empiezo a hacerme esta pregunta es intentar romper el código. Lanza una entrada no válida, especifica valores de configuración incorrectos, etc.

— Zymus

Respuestas:

Para verificar si tiene suficientes pruebas o no, puede verificar la cobertura de su código y la cobertura de su sucursal inducida por las pruebas (tal vez usando una herramienta de cobertura, tal vez manualmente revisando las rutas de código o usando un depurador).

Si llega a la conclusión de que las pruebas para las subclases le brindan una cobertura lo suficientemente alta para su código de clases base, entonces agregar pruebas adicionales obviamente no le brindará muchos beneficios. Por otro lado, si hay rutas de código que solo puede probar agregando pruebas específicas utilizando la clase base directamente, entonces debe seguir esta ruta.

Otra posible razón para "probar su clase base directamente" es que desea probar una función específica de esa clase "aisladamente". A veces puede ser más fácil diseñar casos de prueba directamente para un método específico, en lugar de solo probar ese método indirectamente llamando a los métodos de sus subclases que usan ese método.

Tenga en cuenta que cuando tiene una clase base genérica para la cual el escenario de uso típico es derivar una subclase, su clase base es probablemente abstracta. Entonces, para probar una clase de este tipo, debe hacer una derivación de todos modos. Para esta situación, probar "la clase base directamente" podría significar agregar una derivación especial solo para fines de prueba, por supuesto.

— Doc Brown
fuente

Sí, estoy de acuerdo con las pruebas unitarias directas en la clase base para los métodos más tangiblemente definidos. Lo que no quería hacer es probar toda la metaprogramación ya que las pruebas unitarias en las subclases prueban implícitamente esas cosas.

— Nathan

El diseño de una clase que extiende la clase base / abstracta que solo existe dentro del directorio de prueba y sirve solo para exponer / instanciar la clase base es un enfoque perfectamente legítimo y razonable para obtener la cobertura adecuada de la clase base y la garantía de que los métodos subyacentes son funciona correctamente de forma aislada de las clases más complejas que se utilizan.

@MichaelT: sí. ¿Suena mi respuesta como si tuviera una opinión diferente al respecto?

— Doc Brown

@DocBrown en absoluto: claramente articulaste ese punto. Solo estaba agregando una explicación adicional que habría escrito en mi propia respuesta (si no lo hubiera dicho ya). No quiero escribir una respuesta que hubiera comenzado "Estoy de acuerdo con todo lo que dijo Doc, pero quiero llamar específicamente y escribir más sobre ..."

Las pruebas automatizadas fueron creadas para el beneficio de los programadores, los programadores no fueron creados para servir las pruebas.

Tenemos pruebas para hacernos más productivos y reducir la cantidad de "problemas" de los que se quejan los clientes.

Entonces, dado que tiene pruebas unitarias orientadas al comportamiento que cubren todos los casos en cada subclase, no hay ningún beneficio para el cliente de que también pruebe la clase base directamente. Esto puede confirmarse cambiando algún código en la clase base y viendo si falla una prueba, por ejemplo, una línea de código común, o agregando un "no" a una "declaración if". (Solo verificar que cada línea de código esté cubierta por las pruebas no es lo suficientemente bueno).

Luego nos preguntamos si la prueba lo haría más productivo . Esto puede suceder de varias maneras.

Permitiéndole pensar con más claridad sobre el código, ya que el código está escrito, es poco probable en este caso.
Permitiéndole probar algo de código en la clase base de forma aislada, así que depúrelo más rápido, una vez más poco probable en el caso de que el código ya esté funcionando.
Permitirle cambiar el código en la clase base sin tener que comprender los detalles de la lógica en las subclases, ¿tal vez si está refactorizando el código?

Entonces, dado que las subclases están funcionando, no veo ningún punto en escribir pruebas directas para la clase base. Esto no es hoy, que no habría sido beneficios escribir estas pruebas en un estado temprano.

— Ian
fuente