¿Debo hacer una prueba de los métodos que se heredan de la súper clase?

Question

Actualmente estoy escribiendo una implementación de un controlador JDBC ( sí, lo leíste correctamente ) de forma TDD y aunque solo he terminado los talones de clase en este punto y solo algunas funciones menores, simplemente se me ocurrió que, dado que Statement es una superclase de PreparedStatement , que es una superclase de CallableStatement , ¿qué debo hacer cuando realmente comienzo a Escribir pruebas para mis implementaciones de esas clases, que debería hacer una de estas:

1. Cree un conjunto de pruebas para Statement y luego extienda ese conjunto para obtener pruebas adicionales para PreparedStatement y luego haga lo mismo para CallableStatement .
2. Pruebe cada implementación individualmente, ignorando los métodos heredados de las superclases.
3. Pruebe rigurosamente cada método individualmente para cada clase de implementación; Es posible que algunos métodos heredados funcionen de manera diferente dependiendo de la implementación, después de todo. Una variación leve de esto sería que probaría todos los métodos heredados que utiliza la implementación.

El número dos se siente más natural, pero debido a la razón que he puesto en el tercero, no estoy seguro de si sería prudente hacerlo. Entonces, ¿qué tú crees que debo hacer?

Answer 1

Específicamente, nunca haría la alternativa 1 (permitiendo que la jerarquía de clases de prueba sea la misma que la jerarquía de clases real) si esto significa que se ejecutarán las mismas pruebas repetidamente para cada subclase de prueba. También soy generalmente escéptico con respecto a las clases de prueba de subclases distintas de la clase base de utilidad general.

Normalmente hago 1 prueba para cada clase en una jerarquía, abstracta o no. Por lo tanto, la clase base tiene una prueba separada (generalmente con una subclase privada local de prueba que se usa para probarla específicamente), y utilizo mi conocimiento de las subclases para escribir pruebas adecuadas para cada subclase. Puedo ver en la cobertura las pruebas que faltan, por lo que generalmente no estoy demasiado formalizado por adelantado.

Answer 2

" prueba cada método individual para cada clase de implementación "

En particular, el error de anular un método de superclase correctamente es un error común. El autor de la subclase hace suposiciones sobre la superclase. La superclase cambia y la subclase ahora está rota.

Answer 3

Proporcione suficientes pruebas para que se sienta cómodo, en función de su conocimiento de la implementación. No trato las pruebas de unidad como pruebas de caja negra. Si sabe que la clase base nunca invoca ningún método virtual (o al menos ninguno que esté anulado), tenga en cuenta ese hecho pero no duplique efectivamente las pruebas de unidad que ya ha realizado.

Las pruebas de la unidad se pueden llevar a los extremos, siempre vale la pena equilibrar el valor que se obtiene con el esfuerzo que le está costando.

Answer 4

Con TDD, no debe apuntar a probar métodos, sino el comportamiento o las capacidades de su código. Por lo tanto, al implementar una subclase, puede limitarse a probar solo los comportamientos que son diferentes de la clase base. En caso de duda, escriba una nueva prueba.