Está.
Incluso si solo realiza pruebas unitarias, no es inusual tener más código dentro de las pruebas que el código realmente probado. No tiene nada de malo.
Considere un código simple:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
¿Cuáles serían las pruebas? Hay al menos cuatro casos simples para probar aquí:
El nombre de la persona es null. ¿Se produce realmente una excepción? Eso es al menos tres líneas de código de prueba para escribir.
El nombre de la persona es "Jeff". ¿Recibimos "Hello, Jeff!"respuesta? Eso son cuatro líneas de código de prueba.
El nombre de la persona es una cadena vacía. ¿Qué salida esperamos? ¿Cuál es el resultado real? Pregunta secundaria: ¿coincide con los requisitos funcionales? Eso significa otras cuatro líneas de código para la prueba unitaria.
El nombre de la persona es lo suficientemente corto para una cadena, pero demasiado largo para combinarlo con "Hello, "el signo de exclamación. ¿Qué pasa?
Esto requiere una gran cantidad de código de prueba. Además, las piezas de código más elementales a menudo requieren un código de configuración que inicializa los objetos necesarios para el código que se está probando, lo que a menudo también lleva a escribir trozos y simulaciones, etc.
Si la relación es muy grande, en cuyo caso puede verificar algunas cosas:
¿Hay duplicación de código en las pruebas? El hecho de que sea un código de prueba no significa que el código deba duplicarse (copiado-pegado) entre pruebas similares: dicha duplicación dificultará el mantenimiento de esas pruebas.
¿Hay pruebas redundantes? Como regla general, si elimina una prueba unitaria, la cobertura de la rama debería disminuir. Si no es así, puede indicar que la prueba no es necesaria, ya que las rutas ya están cubiertas por otras pruebas.
¿Está probando solo el código que debe probar? No se espera que pruebe el marco subyacente de las bibliotecas de terceros, sino exclusivamente el código del proyecto en sí.
Con las pruebas de humo, las pruebas de sistema e integración, las pruebas funcionales y de aceptación y las pruebas de estrés y carga, agrega aún más código de prueba, por lo que tener cuatro o cinco LOC de pruebas para cada LOC del código real no es algo de lo que deba preocuparse.
Una nota sobre TDD
Si le preocupa el tiempo que lleva probar su código, es posible que lo esté haciendo mal, es decir, primero el código, luego las pruebas. En este caso, TDD puede ayudarlo al alentarlo a trabajar en iteraciones de 15 a 45 segundos, cambiando entre código y pruebas. De acuerdo con los defensores de TDD, acelera el proceso de desarrollo al reducir tanto la cantidad de pruebas que debe hacer como, y lo que es más importante, la cantidad de código comercial para escribir y especialmente reescribir para pruebas.
¹ Let n sea la longitud máxima de una cadena . Podemos llamar SayHelloy pasar por referencia una cadena de longitud n - 1 que debería funcionar bien. Ahora, en el Console.WriteLinepaso, el formato debe terminar con una cadena de longitud n + 8, lo que dará como resultado una excepción. Posiblemente, debido a los límites de memoria, incluso una cadena que contiene n / 2 caracteres dará lugar a una excepción. La pregunta que uno debe hacerse es si esta cuarta prueba es una prueba unitaria (parece una, pero puede tener un impacto mucho mayor en términos de recursos en comparación con las pruebas unitarias promedio) y si prueba el código real o el marco subyacente.