subscripción
Blog de Julio César Pérez Arques
Buenas prácticas para programar tests
Abril 13th, 2009 - [Enlace local]
[MOD 090413: Modificación de propiedad Repetible]
En todo proceso de construcción moderno y profesional existe una fase de test o pruebas. Esta fase de test cuenta con total protagonismo, como demuestran el tiempo, recursos y herramientas dedicados. No hace falta pensar en la construcción de un puente, un avión o un formula1, piensa simplemente en el proceso de construcción de una batidora.
Este post es una recopilación de buenas práticas para programar tests. Es un pequeño granito de arena para ayudar a fomentar la fase de test en nuestro mundo del desarrollo de software.
Las buenas prácticas están clasificadas según su naturaleza. Y como siempre, son buenas prácticas sólo respecto a mi propia experiencia y criterio. Así que estáis más que invitados a participar.
Propiedades de un test
- Automático. Todos los tests deben poder ejecutarse de forma automática.
- Independiente. El resultado de la ejecución de un test no debe depender de la ejecución de otro test.
- Repetible. El resultado de la ejecución de un test debe ser repetible en el tiempo. Para ello el test no debe depender de las circunstancias del contexto ni otros recursos. Si es necesario el test inicializará el contexto y recursos a un estado conocido o lo simulará mediante Mocks.
Estructura dentro del proyecto
- El código de test debe ir contenido en una carpeta fuente distinta de la del código de la aplicación.
- Una clase test debe pertenecer al mismo paquete que la clase de la aplicación que prueba. De este modo podrá ejecutar no sólo sus métodos públicos, sino también aquellos con modificador protected y package.
Código de test
- El código de test debe tener la misma importancia que el código de aplicación.
- Reutiliza código de test. Usa herencia, clientela y métodos estructurados para reutilizar ese código común que prepara el contexto, la entrada de los métodos o comprueba los resultados.
- Una clase test debe tener un nombre significativo. Por lo general será el mismo nombre que la clase de la aplicación que prueba más el sufijo Test o Tests.
- Un método test debe tener un nombre significativo que resuma claramente el caso de prueba u objetivo del test. Pej. es mucho mejor usar testBuscarProductosPorNombreNoExistente que testBuscarPr4.
- Un método test debe probar un único caso de prueba.
- El código de un método test debe ser comprensible y estar estructurado en (i) preparación del caso de prueba particular y su entrada, (ii) ejecución del caso de prueba (método a probar) y (iii) comprobación del resultado.
- La longitud de un método test debe cumplir los estándares de codificación del equipo. En caso necesario, refactoriza extrayendo métodos reutilizables que ejecuten los pasos de preparación y comprobación.
Casos de prueba
- No te limites al caso de prueba fácil.
- Incluye casos de error como casos de prueba. Pej. crea casos de prueba donde la entrada es incorrecta, saltan excepciones o el resultado debería ser null.
- Crea un caso de prueba para cada bug detectado.
