El código duplicado es un olor en el código de prueba de la unidad tanto como en otros códigos. Si tiene código duplicado en las pruebas, es más difícil refactorizar el código de implementación porque tiene una cantidad desproporcionada de pruebas para actualizar.Las pruebas deberían ayudarlo a refactorizarse con confianza, en lugar de ser una gran carga que le impida trabajar en el código que se prueba.
Si la duplicación está en la configuración del dispositivo, considere hacer más uso del método setUp o proporcionar más (o más flexible) Creation Methods.
Si la duplicación está en el código que manipula el SUT, pregúntese por qué las llamadas pruebas de "unidades" múltiples ejercen exactamente la misma funcionalidad.
Si la duplicación está en las aserciones, entonces tal vez necesite alguna Custom Assertions. Por ejemplo, si varias pruebas tienen una serie de afirmaciones como:
assertEqual('Joe', person.getFirstName())
assertEqual('Bloggs', person.getLastName())
assertEqual(23, person.getAge())
Entonces, tal vez necesite un solo método assertPersonEqual, por lo que se puede escribir assertPersonEqual(Person('Joe', 'Bloggs', 23), person). (O tal vez simplemente necesite sobrecargar el operador de igualdad en Person.)
Como menciona, es importante que el código de prueba sea legible. En particular, es importante que la intención de una prueba sea clara. Encuentro que si muchas pruebas se ven más o menos iguales (por ejemplo, tres cuartas partes de las líneas son iguales o prácticamente iguales) es difícil detectar y reconocer las diferencias significativas sin leerlas cuidadosamente y compararlas. Así que me parece que la refactorización para eliminar la duplicación ayuda a la legibilidad de, porque cada línea de cada método de prueba es directamente relevante para el propósito de la prueba. Eso es mucho más útil para el lector que una combinación aleatoria de líneas que son directamente relevantes, y líneas que son simplemente repetitivas.
Dicho esto, a veces las pruebas están ejerciendo situaciones complejas que son similares pero aún significativamente diferentes, y es difícil encontrar una buena forma de reducir la duplicación. Use el sentido común: si siente que las pruebas son legibles y aclara su intención, y se siente cómodo con la necesidad de actualizar más de un número teóricamente mínimo de pruebas al refaccionar el código invocado por las pruebas, entonces acepte la imperfección y muévase a algo más productivo. ¡Siempre puedes regresar y refactorizar las pruebas más tarde, cuando llegue la inspiración!
"El código duplicado es un olor en el código de prueba de la unidad tanto como en otros códigos". No. "Si ha duplicado el código en las pruebas, es más difícil refactorizar el código de implementación porque tiene una cantidad desproporcionada de pruebas para actualizar". Esto sucede porque estás probando la API privada en lugar de la API pública. –
Pero para prevenir el código duplicado en las pruebas unitarias, generalmente necesita introducir una nueva lógica. No creo que las pruebas unitarias contengan lógica porque entonces necesitarías pruebas unitarias de pruebas unitarias. –