Siguiendo la lógica de #TDD, tus primeros tests en código de producción cuando no tienes experiencia no deberían ser siguiendo TDD
[ H I L O ] ⇩
La lógica de TDD se basa un ciclo red-green-refactor basado en baby steps o pequeños pasos.
Escribes el test más sencillo
El primer step que falle.
El segundo step que funcione.
El tercer step refactor para optimizar el código
Este ciclo se repite a medida que añadimos tests
Esta lógica de ir dando pequeños pasos sigue la tercera ley de hábitos, hazlo fácil.
Es importante para construir un hábito como el de escribir test, empezar haciéndolo fácil porque en base a obtener la recompensa querrás hacer más.
Ya llegará el momento de hacer TDD.
En los cursos de TDD haces el típico Kata Fizz Buzz que esta bien para aprender la técnica y debe ser así, pero la realidad de un proyecto de producción es mucho más compleja.
He visto grandes programadores que les cuesta TDD.
He participado en cursos de testing complejo haciendo screenshot testing y otras técnicas y a los profesores les cuesta TDD.
TDD es una tecnica de testing Avanzada.
Cuando no sabes ni como crear un test, ni te has peleado con dobles de tests no es el escenario ideal.
El primer paso más fácil para aprender a crear tests no es hacerlo usando TDD.
Si quieres adquirir el hábito de escribir test hazlo atractivo y fácil, cuando obtienes la recompensa y tienes experiencia, empieza con TDD.
Las buenas ideas, patrones y principios que se usan en el desarrollo de software, ¿de dónde salen?
[ H I L O ] ⇩
A finales de 1980 @unclebobmartin comenzó a recopilar distintos principios de diseño de software.
Algunos de los principios habían sido formulados por otros colegas, por ejemplo el Principio de Sustitución de Liskov fue enunciado por Barbara Liskov y Jeannette Wing.
@unclebobmartin El Tío Bob por aquella época debatía sobre estos principios con otros colegas en USENET (una especie temprana de Facebook).
A lo largo de los años, los principios fueron cambiado.
Equipo de desarrollo de stack tecnológico .Net Core
Tienen desarrollado API Rest
Tienen problemas de errores, velocidad de desarrollo y mantenimiento de la aplicación. Me piden ayuda
Te cuento más ⬇️
A groso modo me suelo encontrar estas características:
- Capa de controladores usando MediatR para usar el patrón CQRS
- Base de datos -> Sql Server
- ORM - Entity Framework
- Pocos tests unitarios, alguno de integración y end to end
- Entidades anémicas con getters y setters sin comportamiento
- Entidades creadas siguiendo convenciones EF code first
- Handlers usando directamente el contexto de EF