¿Qué hace que una prueba unitaria sea buena? [cerrado]
Estoy seguro de que la mayoría de ustedes están escribiendo muchas pruebas automatizadas y que también se han topado con algunos errores comunes al realizar pruebas unitarias.
Mi pregunta es ¿sigue alguna regla de conducta al redactar exámenes para evitar problemas en el futuro? Para ser más específico: ¿Cuáles son las propiedades de las buenas pruebas unitarias ? o cómo se escriben las pruebas?
Se recomiendan sugerencias independientes del idioma.
Permítanme comenzar conectando fuentes: pruebas unitarias pragmáticas en Java con JUnit (también hay una versión con C#-Nunit... pero tengo esta... es independiente en su mayor parte. Recomendado).
Las buenas pruebas deberían ser UN VIAJE (El acrónimo no es lo suficientemente pegajoso; tengo una copia impresa de la hoja de referencia en el libro que tuve que sacar para asegurarme de haberlo hecho bien).
- Automático : la invocación de pruebas y la verificación de resultados de PASA/FALLA deben ser automáticas.
- Completo : Cobertura; Aunque los errores tienden a agruparse alrededor de ciertas regiones del código, asegúrese de probar todas las rutas y escenarios clave. Utilice herramientas si es necesario para conocer las regiones no probadas.
- Repetible : las pruebas deben producir los mismos resultados cada vez... cada vez. Las pruebas no deben depender de parámetros incontrolables.
- Independiente : Muy importante.
- Las pruebas deben probar sólo una cosa a la vez. Múltiples afirmaciones están bien siempre y cuando todas prueben una característica/comportamiento. Cuando una prueba falla, debería identificar la ubicación del problema.
- Las pruebas no deben depender unas de otras : aisladas. No hay suposiciones sobre el orden de ejecución de la prueba. Asegúrese de hacer borrón y cuenta nueva antes de cada prueba utilizando la configuración y el desmontaje de forma adecuada
Profesional : a largo plazo, tendrá tanto código de prueba como producción (si no más); por lo tanto, siga el mismo estándar de buen diseño para su código de prueba. Métodos-clases bien factorizados con nombres que revelen la intención, sin duplicación, pruebas con buenos nombres, etc.
Las buenas pruebas también se ejecutan rápidamente . cualquier prueba que tarde más de medio segundo en ejecutarse... necesita ser trabajada. Cuanto más tarde en ejecutarse el conjunto de pruebas... con menos frecuencia se ejecutará. Cuantos más cambios intente introducir el desarrollador entre ejecuciones... si algo se rompe... llevará más tiempo descubrir qué cambio fue el culpable.
Actualización 2010-08:
- Legible : esto puede considerarse parte de Professional; sin embargo, no se puede enfatizar lo suficiente. Una prueba de fuego sería encontrar a alguien que no sea parte de su equipo y pedirle que descubra el comportamiento bajo prueba en un par de minutos. Las pruebas deben mantenerse al igual que el código de producción, así que hágalas fáciles de leer incluso si requiere más esfuerzo. Las pruebas deben ser simétricas (seguir un patrón) y concisas (probar un comportamiento a la vez). Utilice una convención de nomenclatura coherente (por ejemplo, el estilo TestDox). Evite saturar la prueba con "detalles incidentales". Conviértase en minimalista.
Aparte de estos, la mayoría de los demás son directrices que reducen el trabajo de bajo beneficio: por ejemplo, "No pruebes código que no sea de tu propiedad" (por ejemplo, archivos DLL de terceros). No vayas a probar captadores y definidores. Esté atento a la relación costo-beneficio o la probabilidad de defectos.
- No escribas pruebas descomunales. Como sugiere la 'unidad' en 'prueba unitaria', haga que cada uno sea lo más atómico y aislado posible. Si es necesario, cree condiciones previas utilizando objetos simulados, en lugar de recrear manualmente gran parte del entorno de usuario típico.
- No pruebes cosas que obviamente funcionan. Evite probar las clases de un proveedor externo, especialmente el que proporciona las API principales del marco en el que codifica. Por ejemplo, no pruebe agregar un elemento a la clase Hashtable del proveedor.
- Considere utilizar una herramienta de cobertura de código como NCover para ayudar a descubrir casos extremos que aún debe probar.
- Intente escribir la prueba antes de la implementación. Piense en la prueba más bien como una especificación a la que se adherirá su implementación. Cfr. también el desarrollo basado en el comportamiento, una rama más específica del desarrollo basado en pruebas.
- Se consistente. Si solo escribe pruebas para parte de su código, no será útil. Si trabajas en equipo y algunos o todos los demás no escriben pruebas, tampoco es muy útil. Convéncete a ti mismo y a todos los demás de la importancia (y las propiedades de ahorro de tiempo ) de las pruebas, o no te molestes.
