Mejores prácticas de nomenclatura de pruebas unitarias [cerrado]
¿Cuáles son las mejores prácticas para nombrar clases de pruebas unitarias y métodos de prueba?
Esto se discutió anteriormente en SO, en ¿ Cuáles son algunas convenciones de nomenclatura populares para las pruebas unitarias?
No sé si este es un muy buen enfoque, pero actualmente en mis proyectos de prueba, tengo asignaciones uno a uno entre cada clase de producción y una clase de prueba, por ejemplo, Producty ProductTest.
En mis clases de prueba tengo métodos con los nombres de los métodos que estoy probando, un guión bajo y luego la situación y lo que espero que suceda, por ejemplo Save_ShouldThrowExceptionWithNullName().
Actualización (julio de 2021)
Ha pasado bastante tiempo desde mi respuesta original (casi 12 años) y las mejores prácticas han cambiado mucho durante este tiempo. Por eso me siento inclinado a actualizar mi propia respuesta y ofrecer diferentes estrategias de denominación a los lectores.
Muchos comentarios y respuestas señalan que la estrategia de nomenclatura que propongo en mi respuesta original no resiste las refactorizaciones y termina con nombres difíciles de entender, y estoy totalmente de acuerdo.
En los últimos años, terminé usando un esquema de nomenclatura más legible para humanos donde el nombre de la prueba describe lo que queremos probar, en la línea descrita por Vladimir Khorikov .
Algunos ejemplos serían:
Add_credit_updates_customer_balancePurchase_without_funds_is_not_possibleAdd_affiliate_discount
Pero como puedes ver es un esquema bastante flexible pero lo más importante es que leyendo el nombre sabes de qué se trata la prueba sin incluir detalles técnicos que pueden cambiar con el tiempo.
Para nombrar los proyectos y las clases de prueba, sigo siguiendo el esquema de respuesta original.
Respuesta original (octubre de 2009)
Me gusta la estrategia de nombres de Roy Osherove . Es el siguiente:
[UnitOfWork_StateUnderTest_ExpectedBehavior]
Tiene toda la información necesaria sobre el nombre del método y de forma estructurada.
La unidad de trabajo puede ser tan pequeña como un único método, una clase o tan grande como varias clases. Debe representar todas las cosas que se van a probar en este caso de prueba y que están bajo control.
Para los ensamblajes uso la .Teststerminación típica, que creo que está bastante extendida y lo mismo para las clases (que terminan en Tests):
[NameOfTheClassUnderTestTests]
Anteriormente, usaba Accesorio como sufijo en lugar de Pruebas, pero creo que este último es más común, luego cambié la estrategia de nomenclatura.
Me gusta seguir el estándar de nomenclatura "Debería" para las pruebas mientras nombro el dispositivo de prueba según la unidad bajo prueba (es decir, la clase).
Para ilustrar (usando C# y NUnit):
[TestFixture]
public class BankAccountTests
{
[Test]
public void Should_Increase_Balance_When_Deposit_Is_Made()
{
var bankAccount = new BankAccount();
bankAccount.Deposit(100);
Assert.That(bankAccount.Balance, Is.EqualTo(100));
}
}
Porque deberia" ?
Encuentro que obliga a los redactores de la prueba a nombrar la prueba con una oración como "Debería [estar en algún estado] [después/antes/cuando] [la acción tiene lugar]".
Sí, escribir "Debería" en todas partes resulta un poco repetitivo, pero como dije obliga a los escritores a pensar de la manera correcta (por lo que puede ser bueno para los principiantes). Además, generalmente da como resultado un nombre de prueba legible en inglés.
Actualizar :
Me di cuenta de que Jimmy Bogard también es fanático de "debería" e incluso tiene una biblioteca de pruebas unitarias llamada debería .
Actualización (4 años después...)
Para aquellos interesados, mi enfoque para nombrar pruebas ha evolucionado a lo largo de los años. Uno de los problemas con el patrón debería que describo anteriormente es que no es fácil saber de un vistazo qué método está bajo prueba. Para la programación orientada a objetos, creo que tiene más sentido comenzar el nombre de la prueba con el método bajo prueba. Para una clase bien diseñada, esto debería dar como resultado nombres de métodos de prueba legibles. Ahora uso un formato similar a <method>_Should<expected>_When<condition>. Obviamente, dependiendo del contexto, es posible que desees sustituir los verbos debería/cuándo por algo más apropiado. Ejemplo:
Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()
