Es necesario sumarizar en el método de prueba unitaria

Dado que la denominación de un método de prueba unitario hace que su propósito sea más significativo, ¿es necesario agregar un resumen al método de prueba de la unidad?Es necesario sumarizar en el método de prueba unitaria

Ejemplo:

/// <summary> 
/// Check the FormatException should be thrown when a give country data line contains a invalid number. 
/// </summary> 
[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
}

Fuente

2009-09-14 Ji Yalin

¿Alguien más ve a Skeet responder extrañamente y luego lo borra casi inmediatamente después? – Will

@Will - sí lo noté también. –

@ Will- ¿Importa? – RichardOD

Creo que el largo nombre descriptivo es más importante que el comentario XML. Como la prueba unitaria no formará parte de una API, no necesita el comentario XML.

Por ejemplo:

[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
}

es más útil que:

///<summary> 
/// Exception Should Thrown When Parse CountryLine Containing InvalidNumber 
///</summary> 
[TestMethod] 
public void Test42() 
{ 
    ... 
}

XML comentarios deben ser utilizados para la documentación de APIs y los marcos.

Fuente

2009-09-14 14:22:15 jrcs3

+1 de mi parte. Además, nunca he visto documentación de pruebas unitarias. Si el código está bien compuesto, debe ser autodescriptivo. Esto es típico si utiliza métodos compuestos: http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html – RichardOD

es necesario, pero si se siente los comentarios XML agregan valor por encima y más allá del nombre de la propia unidad de prueba (que parece ser exhaustivo), entonces se va a realizar otra desarrolladores un servicio.

Si el resumen es esencialmente un duplicado directo del nombre del método de prueba de unidad, entonces yo creo que esto es una exageración.

Fuente

2009-09-14 14:16:05

Personalmente, trato de hacer las pruebas suficientes fácil de leer que la documentación sería redundante. Yo uso comentarios en línea en el método de ensayo para explicar por qué estoy haciendo algo de una manera particular, no lo que estoy haciendo.

Fuente

2009-09-14 14:16:19

-1

Si crees que es el mejor uso de tu tiempo, hazlo, de lo contrario no lo hagas. No lo haría.

Fuente

2009-09-14 14:16:50 erikkallen

Para el ejemplo anterior, yo diría que no es necesario, a menos que utilice una herramienta que extrae la documentación de la fuente (como javadoc o algo así).

Una regla general es que el código dice lo que estás haciendo y el comentario dice por qué, pero dado que el nombre es muy detallado (que creo que está bien, ya que nadie tiene que escribirlo) no creo que el comentario contribuya nada.

Fuente

2009-09-14 14:21:14

Es necesario añadir un resumen en el resumen puede dar más información que puede/debe ser codificado en nombre del método. Tenga en cuenta que cuando digo "necesario" cuando me refiero a cualquier documentación, me refiero es "necesario para transmitir el 100% del contexto/detalles/matices necesarios a un nuevo codificador heredando el proyecto o usted mismo 5 años después".

Fuente

2009-09-14 14:22:06 DVK

En realidad, prefiero usar la DescriptionAttribute sobre una etiqueta de resumen. El motivo es que el valor del atributo Descripción aparecerá en un archivo de resultados. Esto hace que los fallos más fácil de entender cuando estás buscando en un archivo de registro

[TestMethod,Description("Ensure feature X doesn't regress Y")] 
public void TestFeatureX42() { 
    .. 
}

Fuente

2009-09-14 14:26:17 JaredPar

Esto se muestra en la lista de prueba, que puede ser útil. – Will

+1. Sí, eso parece una buena idea. – RichardOD

+1 De mí también. La convención de nombres para los métodos debe mantenerse para todos los proyectos, incluidos los de prueba: ¿cuál es la razón para poner un resumen o una descripción en el nombre del método en lugar de lugares diseñados para guardar esos datos? – Spook

Un comentario XML es totalmente innecesario si tiene un nombre de método descriptivo. Y es imprescindible para los métodos de prueba unitaria.

Ya está en la pista correcta con un nombre de método de prueba descriptivo. (Muchos practicantes de TDD y ágiles creen que un método de prueba debe incluir "debería", por ejemplo, como se muestra en link text este blog.

Personalmente, me gustan los nombres de método como este:

MyClass_OnInvalidInput_ShouldThrowFormatException()

Pero eso es sólo mi preferencia personal.

Fuente

2009-09-14 15:10:25 azheglov

Es necesario sumarizar en el método de prueba unitaria

Respuesta

Cuestiones relacionadas