He estado trabajando con TDD durante 2 años y donde trabajé en ese momento, todos estábamos reacios a usar, incluidos los gerentes. Sin embargo, pronto se convirtió en lo correcto. Los beneficios que pronto notamos fueron
- Descubrir errores en una etapa temprana.
- Escribiendo mejor código sin siquiera darnos cuenta.
- Su código ahora es más mantenible debido a sus pruebas
es todo en pequeños trozos (tuvimos funciones que eran 300-400 líneas) tonto. Ahora max 30 y todo
independientemente probado.
Los gerentes no sabrían ya que todos están interesados en una cosa: "¿Ya terminaste?".
Pero luego se quejan cuando el software sigue rompiendo sin darse cuenta.
Con una buena cobertura y pruebas sensatas. No es la cantidad sino la calidad que se puede ver cuando alguien rompe una funcionalidad.
Desafortunadamente, también es difícil si está solo. Tenía el mismo problema, ya que es posible que necesite cambiar el código, por ejemplo, las clases base, etc. para que pueda hacer que algunas partes del software sean verificables.
Te doy un ejemplo. Quería burlarme del repositorio pero no había ninguna interfaz y necesito inyectar el repositorio en mi capa de servicio y, por lo tanto, agregar / modificar un constructor en toda la tienda, esto resultó ser una gran trato pero al final tengo más de 200 pruebas que solo prueban un área del sistema y quedaron impresionados.
Normalmente hago lo siguiente:
- Mantengo mis pruebas de unidad muy cortas
- Sólo 1 afirma .No ruleta rusa.
- Pruebo un escenario positivo -negativo y de excepción
En cuanto a los estudios de caso, me temo que no estoy seguro de haber visto ninguno. Necesitas construir tu proyecto y convertirte en tus estudios de caso. También podrían estar impresionados.
Espero que ayude