¿Cómo pruebo la unidad de las funciones sobrecargadas?

Question

así que tengo una clase que se ve algo como lo 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; 
    } 

} 

Dónde DbParameter es una clase de valor simple que contiene propiedades como servidor, DBName, DbType, etc.

Ahora, quiero añadir una sobrecarga a DoSomething para que acepte una cadena de conexión en lugar del parámetro DBParameter (suponiendo que DatabaseDependency ya tiene una sobrecarga de 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 agregue la sobrecarga a DoSomething, esencialmente refactorizaría el código para que ambas sobrecargas reutilicen esta lógica (es decir, probablemente la mueva a un método privado). ¿Cuál es la forma correcta de realizar esta prueba unitaria? ¿Debo tener tantas 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 se delega en el original, debe agregar un método de prueba más.

Sin embargo, esto se rompe si refactoriza los métodos subyacentes sobrecargados de modo que no se lleve a cabo ninguna delegación. En este escenario, me sentiría más seguro replicando 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 el 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

Sí, refactorice el procesamiento común a un método privado - Supongo que lo haría 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 3

Si su código sigue siendo el mismo en el que se ve actualmente, entonces sí: también deberá probar ese método, 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 prueba en la que simplemente verifique que el otro método invoque el método virtual con los valores correctos.

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

Answer 4

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

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

Si su aplicación utiliza solo un método, desaprobar el otro y crear una prueba condicional de versión que falle cuando aún exista el método obsoleto en una versión predeterminada. IE: hacer cumplir que el método obsoleto se elimina en algún momento.