Cree una prueba JUnit para un método que cubra todas sus invocaciones en el espacio de trabajo de Eclipse

Question

Supongamos la siguiente clase de Java:

class MyClass {
   public String methodA( String data, String expression ) {
      // expression is evaluated using data
      // ...
      // this leads to a result which is returned
      return result;
   }
}

Tenga en cuenta que expression es una instancia de un lenguaje de expresión (DSL).Así, la evaluación de expression usando data depende de la combinación de ambos.Normalmente, expression es un valor fijo que no cambia con frecuencia y data puede cambiar a lo largo de todas las invocaciones.

Bueno, algún tiempo después se encuentra un error en MyClass.methodA(String,String).El error reside en alguna clase subyacente y sólo ocurre para alguna combinación especial de expression y data.Se escribe fácilmente una prueba JUnit para este caso especial y se puede solucionar.

Lamentablemente, este método se utiliza con frecuencia en todo el proyecto.La jerarquía de llamadas de Eclipse identifica más de 97 métodos más donde se utiliza este método.Ahora temo la regresión, si simplemente aplico la corrección de errores.Para sentirme más seguro, me gustaría hacer algunas pruebas de regresión.

Normalmente, las pruebas unitarias deberían considerar todos los tipos importantes de invocaciones, especialmente los casos fronterizos.Pero como expression es un DSL que puede variar mucho, no es fácil probar y cubrir todos los usos potenciales.Además, esas pruebas no identificarían un uso falso basándose en el error.

Entonces mi idea es proceder de la siguiente manera:

1. Encuentre todas las invocaciones de este método (como usar "Jerarquía de llamadas" en Eclipse) y extraiga todos los valores para expression.

2. Muestra suficientes valores de la vida real para data (p.ej.de la base de datos) y realizar una evaluación cruzada de todas las expresiones desde el primer paso utilizando la versión original de MyClass.methodA(String,String).salva los triples (data, expression, result) a un archivo.

3. Implementar corrección de errores.

4. Método de prueba MyClass.methodA(String,String) utilizando el archivo anterior para afirmar que los resultados no han cambiado.

Siguientes preguntas:

Que piensas de esta aproximación?

Al usar la jerarquía de llamadas en Eclipse, solo puedo copiar y pegar los métodos de llamada, pero no la invocación exacta, incluidos los argumentos, en el portapapeles (cf.paso 1).Tendría que copiar la llamada de invocación a mano para cada método encontrado.¿Cómo extraigo las invocaciones de una manera conveniente (en el espacio de trabajo completo de Eclipse, por lo tanto, en varios proyectos)?

En mi humilde opinión, solo estoy probando un método, por lo que las pruebas cubren solo una unidad.¿Está bien usar JUnit para el paso 4 o hay algo más sofisticado?

Answer 1

Como el valor adicional esperado al probar su software es cubrir la mayoría de las circunstancias con los costos más bajos y el máximo resultado, estoy de acuerdo con su enfoque.

Recopilar valores de muestra de la vida real de su software y guardarlos en un archivo representativo no debería ser tan complejo de realizar y me parece la mejor manera de analizar esto.Incluso si tienes que copiarlo manualmente.