En la lección anterior, creamos un pequeño ejemplo base utilizando Composer, PHPUnit y otras dependencias, en esta lección agregaremos comportamiento adicional a la clase de ejemplo (Mailer) y para ello utilizaremos condicionales, lo cual complicará el código de varias maneras que nos llevarán a visualizar porqué necesitamos aplicar refactorización y un patrón de diseño (en nuestro caso, Strategy) para solucionar los inconvenientes.
Repositorio
Ver el código de esta lección en GitHub
Notas
Si tu prueba interactúa con algún tipo de mecanismo que persista datos o archivos (base de datos, sistema de archivos, API, etc.) debes asegurarte que el estado del que parta la prueba sea siempre el mismo (por ejemplo refrescar la base de datos, vaciar la bandeja de entrada de MailTrap, eliminar los archivos de prueba, etc.) de lo contrario puedes obtener falsos positivos (es decir que la prueba pase cuando debería fallar).
Nunca coloques información confidencial como tokens o contraseñas dentro de tus clases, para ello deberías usar variables de entorno y mantenerlas de la manera más confidencial posible, por ejemplo no compartiéndolas en el repositorio de git.
Actividad
Menciona y discute con otros compañeros los diferentes problemas en el código desarrollado durante estas dos lecciones antes de pasar a la siguiente lección (donde finalmente aplicaremos el Patrón Strategy).
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
Lección anterior Patrón Strategy: Creación del proyecto de ejemplo Lección siguiente Aplicación del Patrón Strategy