¿Debo duplicar las pruebas de sobrecargas de conveniencia?

Question

Es muy común para mí hacer sobrecargas de conveniencia para los métodos. Aquí está un ejemplo de algo que podría hacer:

public void Encode(string value) { 
    Encode(value, DefaultEncoding); 
} 

public void Encode(string value, Encoding encoding) { 
    // ... 
} 

estoy empezando a prestar más atención a la unidad de pruebas y métodos de prueba de este tipo presenta algunos obstáculos que no estoy seguro de que confiar en mí mismo para acercarse a solas. El primer y más importante problema es si debería duplicar las pruebas para ambas sobrecargas. Por ejemplo, ambos métodos deberían arrojar ArgumentNullException si el valor es nulo; ¿Es más correcto reconocer que podría ser lógica diferente y escribir dos pruebas o es mejor asumir que las sobrecargas de conveniencia no tienen lógica propia?

También tengo un problema secundario. Mi esquema de nombres es el mismo que el de Roy Osherove: "MemberName_State_ExpectedResult". Si duplico las pruebas, entonces tengo nombres discordantes sin introducir alguna convención de nombres extravagantes. ¿Cómo manejas esto si duplicas las pruebas?

Answer 1

Con frecuencia no pruebo los métodos de conveniencia con el mismo nivel de detalle que el método central que llaman. Por ejemplo, su caso ArgumentNullException. No lo probaría dos veces. Mi sensación es que las pruebas unitarias son pruebas de caja blanca. Se me permite saber la implementación.

Por supuesto, esto podría significar que me voy a quemar cuando voy a refactorizar más tarde y agregue funcionalidad al método de conveniencia. Pero soy bastante bueno haciendo TDD (no es un fanático total como se puede ver en el primer párrafo). Así que creo que lo más probable es que escriba una prueba para esa nueva funcionalidad y la cubra en ese momento.

No estoy diciendo que sea más o menos correcto. Es solo lo que hago.

Answer 2

Si todos sus constructores llamar al constructor especificada completamente, me rompería las pruebas en
1) la prueba de la unidad actual, que debe ser algo como
ConstructorShouldDoThisAndThat()
2) pruebas de la unidad especializada para las sobrecargas , especificando lo que por defecto los usos de sobrecarga, como ConstructorWithNoEncodingShouldSetEncodingToDefaultEncoding()

Answer 3

"escribir dos pruebas o es mejor asumir que las sobrecargas de conveniencia no tienen su propia lógica?"

Umm .... Sus pruebas no están definidas por "suposiciones". Están definidos por el diseño de la clase que estás probando.

No hace nada en función de "suposiciones".

Si la función de conveniencia es en realidad una función de conveniencia, se debe hacer lo mismo y que debe escribir una prueba que demuestra que ambos métodos variantes en realidad hacen lo mismo.

Si "no podría ser lógica diferente" (1) no es realmente una función de conveniencia y (2) que debe escribir una prueba que demuestra que ambos métodos variantes en realidad hacen lo correcto (que puede ser lo mismo con lógica diferente, o puede ser diferente, no puedo decirlo a partir de la pregunta.)

"MemberName_State_ExpectedResult. Si duplico pruebas, entonces no tengo los nombres de choque"

evitar preguntas consistencia estúpida. Si tiene el mismo método con diferentes firmas, entonces esta convención de nomenclatura no es muy buena, ¿verdad? Mantenerlo fielmente, a pesar de sus problemas, es una consistencia tonta.

No se puede usar trivialmente cuando tiene métodos que se distinguen solo por firmas de argumento. Así que solo invente algo que funcione para todas sus funciones de conveniencia.

Answer 4

Creo que la respuesta es más simple, entonces piensas: ¿te importa si los métodos sobrecargados funcionan o no? Si te importa que funcionen, ¿cómo sabes con certeza a menos que los pruebes?

Le tomará unos 15 segundos escribir una prueba que compare la salida de la función sobrecargada con la que sobrecarga. Hazlo y sigue adelante.

Answer 5

Lo que suelo hacer es hacer el método "real" virtual. Esto significa que puedo probar el método de conveniencia utilizando una clase derivada específica de la prueba (generalmente creada por una simulación dinámica) para verificar que llame correctamente al método "real".

Si la única diferencia entre el método "real" y el método de conveniencia es el uso de un valor predeterminado para un parámetro en particular, puede cubrirlo con una prueba de unidad única y continuar.

Respondo la respuesta de S.Lott respecto a la convención de nomenclatura.