¿Cómo pruebo la unidad las funciones sobrecargadas?

Question

Entonces tengo una clase que se parece a la siguiente:

public class MyClass
{

    DatabaseDependency _depend;

    public MyClass(DatabaseDependency depend)
    {
        _depend = depend;
    }

    public string DoSomething(DBParameter database)
    {
        var result = _depend.GetResults(database, ...);
        string response = String.Empty;        

        // some logic to process the result 

        return response;
    }

}

Donde DBParameter es una clase de valor simple que contiene propiedades como Servidor, DBName, DBType, etc.

Ahora, quiero agregar una sobrecarga a DoSomething para que acepte una cadena de conexión en lugar del parámetro DBParameter (suponga que DatabaseDependency ya tiene una sobrecarga GetResults que acepta una cadena de conexión).

Mi pregunta: Tengo varias pruebas unitarias que describen las diversas rutas lógicas utilizadas para procesar el resultado de DatabaseDependency.GetResults. Cuando agrego la sobrecarga a DoSomething, esencialmente refactorizaría el código para que esta lógica sea reutilizada por ambas sobrecargas (es decir, probablemente lo mueva a un método privado). ¿Cuál es la forma correcta de hacer que la unidad pruebe esto? ¿Necesito tener la misma cantidad de pruebas unitarias para verificar todas las rutas lógicas para la nueva sobrecarga que estoy agregando?

Answer 1

Si está seguro de que su método sobrecargado que toma una cadena simplemente se convierte en un objeto de conexión y luego delega al original, debe agregar un método de prueba más.

Sin embargo, esto se rompe si refactoriza los métodos sobrecargados subyacentes de modo que no se realice ninguna delegación. En este escenario, me sentiría más seguro al replicar todas las pruebas para ambos métodos.

Creo que la primera ruta es la más pragmática. Sin embargo, es una buena idea ejecutar análisis de cobertura de código de vez en cuando, y eso indicará más adelante si se requieren más pruebas.

Answer 2

Si su código permanece como se ve actualmente, entonces sí: necesitará probar ese método también, esencialmente duplicando su esfuerzo de prueba.

Sin embargo, si tiene sentido implementar la funcionalidad para que un método simplemente llame al otro, puede hacer que ese otro método sea virtual. Eso le permitiría crear una subclase específica de la prueba en la que simplemente verifique que el otro método invoque el método virtual con los valores correctos.

Una vez que se haya verificado mediante una o más pruebas unitarias, no necesita probar ese método más, porque ahora ha probado que el método llama al otro método correctamente, y puede concentre sus esfuerzos de prueba en ese método.

Answer 3

Sí, refactorice el procesamiento común a un método privado. Supongo que haría esto de todos modos, independientemente de las consideraciones de la prueba, el código duplicado es malo. Es interesante cómo pensar en las pruebas nos lleva a hacer lo correcto.

Luego tiene un par de pruebas simples para cada ruta de iniciación superpuesta.

Answer 4

Depende de si está haciendo pruebas de caja negra o de caja blanca y también si su aplicación está utilizando ambas versiones del método.

Si está asumiendo que solo está probando la implementación, simplemente probar la versión 'principal' estaría bien. Si está pensando en la línea de un escritor de pruebas que solo conoce la API presentada (javadocs o similar), entonces debe realizar una prueba basada solo en la API, lo que implica probar ambos métodos por completo.

Si su aplicación usa solo un método, desaproveche el otro y cree una prueba condicional de versión que falle cuando el método desaprobado todavía exista en alguna versión predeterminada. IE: exigir que el método obsoleto se elimine en algún momento.