Si los nombres de las pruebas unitarias pueden quedar obsoletos con el tiempo y si considera que la prueba en sí misma es lo más importante, ¿es importante elegir los nombres de las pruebas inteligentes?¿Son importantes los nombres de las pruebas de unidad?
es decir
[Test]
public void ShouldValidateUserNameIsLessThan100Characters() {}
verso
[Test]
public void UserNameTestValidation1() {}
El nombre de cualquier método debe aclarar lo que hace.
IMO, su primera sugerencia es un poco larga y la segunda no es lo suficientemente informativa. También es probable que sea una mala idea poner "100" en el nombre, ya que es muy probable que cambie. ¿Qué pasa con:
public void validateUserNameLength()
Si la prueba cambia, el nombre debe actualizarse en consecuencia.
No voy a poner condiciones que debe cumplir la prueba en el nombre, ya que las condiciones pueden cambiar en el tiempo. en su ejemplo, me gustaría recomendar nombrar como
UserNameLengthValidate()
o
UserNameLengthTest()
o algo similar para explicar lo que hace la prueba, pero no suponiendo los parámetros de prueba/validación.
Creo que si uno no puede encontrar un buen nombre conciso para un método de prueba, es una señal de que el diseño de esta prueba es incorrecto. También un buen nombre de método te ayuda a descubrir qué sucedió en menos tiempo.
El nombre debe ser importante. No quiero un correo electrónico de la compilación que diga que la prueba 389fb2b5-28ad3 falló, pero el solo hecho de saber que era una prueba de nombre de usuario en lugar de otra cosa ayudaría a asegurar que la persona correcta haga el diagnóstico.
Sí, los nombres del código bajo prueba (métodos, propiedades, lo que sea) pueden cambiar, pero sostengo que las pruebas existentes deberían fallar si cambian las expectativas. Ese es el verdadero valor de tener pruebas bien construidas, sin leer detenidamente una lista de nombres de pruebas. Dicho esto, los métodos de prueba bien nombrados son excelentes herramientas para atraer a nuevos desarrolladores, ayudándoles a encontrar "documentación ejecutable" con la que puedan patear los neumáticos del código existente, para mantener actualizados los nombres de los métodos de prueba solo ya que mantendría al día las afirmaciones hechas por los métodos de prueba.
Indico mi prueba utilizando el siguiente patrón. Cada accesorio de prueba intenta enfocarse en una clase y generalmente es prueba de nombre {ClassUnderTest}. Yo nombro cada método de prueba {MemberUnderTest} _ {Afirmación}.
[TestFixture]
public class IndexableFileTest
{
[Test]
public void Connect_InitializesReadOnlyProperties()
{
// ...
}
[Test,ExpectedException(typeof(NotInitializedException))]
public void IsIndexable_ErrorWhenNotConnected()
{
// ...
}
[Test]
public void IsIndexable_True()
{
// ...
}
[Test]
public void IsIndexable_False()
{
// ...
}
}
Muy. Igualmente importante que elegir buenos métodos y nombres de variables.
Mucho más si los desarrolladores nuevos se refieren a su conjunto de pruebas en el futuro.
En cuanto a su pregunta original, definitivamente Answer1. Escribir en algunos caracteres más es un pequeño precio a pagar por
Sí.
[Test]
public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {}
Coloque el sujeto de prueba primero, la declaración de prueba a continuación y el último resultado esperado.
De esta forma, obtiene una indicación clara de lo que está haciendo, y puede ordenar fácilmente por nombre :)
Sí, el objetivo del nombre de la prueba es que le dice lo que no funciona cuando la prueba falla
[RowTest]
[Row("GoodName")]
[Row("GoodName2")]
public void Should_validate_username()
{
}
[RowTest]
[Row("BadUserName")]
[Row("Bad%!Name")]
public void Should_invalidate_username()
{
}
Esto podría tener más sentido para los tipos más complejos de validación realmente.
Sí, lo son. Yo personalmente recomendaría mirar SSW's rules to better unit tests. Contiene algunas pautas de nombres muy útiles.
Sí, los nombres son totalmente importantes, especialmente cuando se ejecutan las pruebas en consola o servidores de integración continua. Jay Fields escribió un post about it.
Además, ponga buenos nombres de prueba con one assertion per test y su suite le dará excelentes informes cuando falla una prueba.
+1 por una afirmación por prueba –
Tener un nombre muy descriptivo ayuda a ver instantáneamente lo que no funciona correctamente, por lo que no es necesario que vea el código de prueba de la unidad. Además, una lista de todas las pruebas unitarias describe el comportamiento previsto de la unidad y se puede usar (más o menos) como documentación del comportamiento de la unidad bajo prueba.
Nota, esto solo funciona cuando las pruebas unitarias son muy específicas y no se validan demasiado en una prueba unitaria.
Así, por ejemplo:
[Test]
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100()
[Test]
void TestThatStringLengthOf99IsAccepted()
En Clean Code, página 124, Robert C. Martin escribe:
La moraleja de la historia es simple: Código de ensayo es tan importante como el código de producción. No es un ciudadano de segunda clase. Requiere pensamiento, diseño y cuidado. Debe mantenerse tan limpio como el código de producción.
¡Así es como a mí me gusta! –