unit testing - unitarias - Señales de advertencia para código inestable
unit test dotnet (10)
Bases de datos! ¡Particularmente aquellos con disparadores!
Sé que puedes burlarte de la base de datos, pero siempre he descubierto que la mayoría de los errores en mi código (principalmente aplicaciones CRUD) son problemas de datos / mapeo y si te burlas de la base de datos no encuentras ese tipo de error.
El código que no puede ser comprobado realmente me molesta. Las siguientes cosas hacen que oo-code no sea comprobable:
- estados globales, por ejemplo, el patrón de diseño de Singleton
- métodos estáticos que hacen un trabajo elegante, por ejemplo, acceso a la base de datos
- árbol de herencia profunda
- trabajar en constructor, por ejemplo, declaraciones de control
- clases que violan el Principio de Responsabilidad Individual
¿Hay más señales de advertencia?
Dependencias codificadas
Diría que ninguna de esas cosas hace que el código no sea comprobable. Ellos hacen las pruebas unitarias difíciles, porque cada una de ellas aumenta el acoplamiento en su implementación.
Entre otras molestias que dificultan las pruebas unitarias:
- código de interfaz gráfica de usuario mezclado con código de lógica de negocios
- todos los antipatrones, pero Dios se opone en particular ( http://en.wikipedia.org/wiki/God_object )
- en la misma línea, una función enorme también es muy molesto
En general, cualquier recomendación que pueda escuchar sobre la creación de un mejor código es también una recomendación para facilitar el código de prueba unitaria.
El código no puede ser validado, siempre que no pueda modificarlo. Si tiene la posibilidad de refactorizar el proyecto, ningún código es imposible de verificar. Por lo general, solo se necesitan modificaciones muy pequeñas para facilitar las pruebas. Y pueden justificarse porque aumentan la calidad del código.
Incluso en los casos que describes, el código no es necesariamente no comprobable. Es simplemente más difícil de probar. Por ejemplo, es más fácil probar el código si puede aislar el acceso a la base de datos y evitarlos durante las pruebas de su unidad. Pero si es necesario, puede poner una base de datos dedicada a ejecutar sus pruebas.
La Guía de Miško Hevery sobre la escritura del código testable detalla los defectos que hacen que el código sea difícil de probar. Su lista se superpone con la tuya un tanto, pero entra en detalles increíbles.
- Constructor hace trabajo real
- Excavar en Colaboradores
- Estado global frágil y Singletons
- La clase hace demasiado
Trabajo realizado en clases de GUI que no tiene nada que ver con la presentación. La GUI debe estar completamente desacoplada del modelo subyacente.
Vea la siguiente publicación de blog de Miško Hevery: Cómo escribir 3v1L, código indiscutible .
falta de capas, exceso de acoplamiento ... es decir, la clase Y se ha escrito para saber acerca de X, pero no debería, X es reutilizable. Existe una fuerte relación entre la capacidad de prueba y la reutilización.
- No programando a las interfaces
- Nuevos objetos para el uso de fábricas / IOC
Ninguna de esas cosas hace que el código no sea comprobable. Pueden dificultar la búsqueda de errores en el borde del caso pero, siempre que haya especificado los criterios de éxito para las pruebas (y el desarrollo basado en pruebas lo facilita), todo lo que tiene que hacer es aprobar los criterios.
TDD puede aplicarse al comportamiento de partes específicas, así como del proyecto en su conjunto, de modo que puede probar fácilmente componentes muy pequeños. Pero, está destinado a probar los resultados, no los medios por los cuales se obtuvieron esos resultados.
Siempre que las pruebas hayan sido aprobadas, ha cumplido con los requisitos. Si hay errores después de eso, este es un problema con las pruebas, no con el código que se está probando (en cuyo caso las pruebas deben modificarse para detectar el problema previamente no previsto).
No debe importar (en términos de entrega de funcionalidad) si hay una instrucción while en uno de sus constructores. Debería preguntarse qué requisitos empresariales así lo exigen. Dudo mucho que su cliente entregue una lista de requisitos que incluya "herencia limitada a 4 niveles". Es muy posible que incluyan una lista de "sin errores" como un requisito, pero tendrá que negociarlos con ese :-).