Cuando terminas un reto técnico en Angular, validar tu solución no se trata solo de hacer clic y ver que la app funcione. La verdadera prueba está en correr los tests de integración end to end y enviar un pull request limpio al repositorio original. Aquí te muestro cómo cerrar ese ciclo y dejar tu proyecto listo para tu portafolio.

¿Cómo validar manualmente la app de tareas antes de enviarla?

Antes de tocar la terminal, conviene revisar que la interfaz responda como debe. La idea es simular el uso real que haría cualquier usuario.

En la solución propuesta, ni el footer ni la sección principal aparecen si no existen tareas. Al escribir algo como "task one", la aplicación arranca con el focus en el input desde el inicio. Si creas una tarea con espacios extra, el sistema los limpia automáticamente y deja solo el texto.

La app también maneja pluralización dinámica: muestra "one item" cuando hay una sola tarea y cambia a plural cuando hay dos o más. Los filtros por estado funcionan así:

• Pending: muestra solo las tareas pendientes.
• Completed: si no hay completadas, indica que no hay tareas en ese estado.
• All: lista todas las tareas existentes.

Además aparece el botón clear tasks para limpiar la lista. Todo esto se valida a ojo, pero la verificación seria llega después.

¿Por qué correr los tests end to end es el paso decisivo?

La validación manual te da una primera señal, pero los tests de integración end to end son los que confirman que cumples cada requisito de la documentación. Desde la terminal ejecutas el comando end-to-end, que construye la aplicación y valida los 20 tests definidos para este reto.

¿Qué son los tests end to end en Angular? Son pruebas automatizadas que ejecutan la aplicación completa como lo haría un usuario real. Validan flujos enteros, no funciones aisladas, y confirman que cada requisito funcional se cumple.

Cuando los 20 tests pasan, tienes la certeza de que tu propuesta cumple los criterios técnicos. Recién ahí tiene sentido preparar el pull request.

¿Qué arquitectura usa la solución propuesta?

La solución se apoya en dos servicios principales que separan responsabilidades con claridad.

El primero es el local storage service, que se encarga únicamente de guardar y leer la información en local storage del navegador, usando una key específica para identificar los datos de la app.

El segundo es el todo service, donde vive toda la lógica de creación y edición de tareas. Concentrar la lógica en un solo servicio facilita la comunicación con los componentes y mantiene el código ordenado.

Dentro del todo service se aplica programación reactiva, un paradigma que Angular potencia con sus herramientas nativas y que permite que los componentes respondan automáticamente a los cambios de estado sin lógica extra.

¿Qué es la programación reactiva en Angular? Es un estilo donde los datos fluyen como streams y los componentes reaccionan a sus cambios en tiempo real. En Angular se trabaja con observables y operadores para mantener la interfaz sincronizada con el estado.

Revisar esta arquitectura te sirve como punto de comparación: mira en qué se parece a tu propuesta y en qué se diferencia.

¿Cómo enviar tu pull request al repositorio original?

Una vez que tu solución pasa todos los tests, GitHub te muestra un mensaje en tu fork indicando la rama donde trabajaste. Si usaste una rama separada, el aviso aparece automáticamente; si trabajaste sobre master, también puedes enviarlo sin problema.

El flujo para enviar tu propuesta a Platzi es directo:

1. Hacer clic en compare and pull request.
2. Escribir una descripción general de tu solución, no demasiado extensa pero sí informativa.
3. Mencionar decisiones clave: si usaste servicios, programación reactiva, división de componentes.
4. Crear el pull request hacia el repositorio original.

Después de enviarlo, GitHub te redirige al repositorio de Platzi y dispara los tests nuevamente, esta vez en servidores de integración continua. Que los tests pasen en tu máquina está bien, pero la validación final ocurre en estos servidores externos.

¿Qué es la integración continua? Es la práctica de ejecutar pruebas automáticas cada vez que se sube código nuevo a un repositorio. Verifica en un entorno controlado que los cambios no rompan nada antes de fusionarse.

Cuando todos los tests terminan correctamente, aparece una marca de verificación verde junto a tu pull request. Esa palomita confirma que tu solución cumple los requisitos estándar del reto.

¿Cómo aprovechar los pull requests de otros estudiantes?

La sección de pull requests del repositorio original es una mina de oro. Ahí no encuentras solo tu solución: encuentras todas las propuestas que otros estudiantes han enviado para el mismo reto.

Puedes filtrar por las que tienen el check verde, que son las que pasaron toda la suite de tests, e inspeccionar cómo resolvieron el mismo problema con enfoques distintos. Es una forma rápida de ampliar tu repertorio de patrones y descubrir alternativas que quizá no consideraste.

Una vez que tu pull request está aprobado, tienes un proyecto sólido listo para tu portafolio profesional. Si te quedan dudas sobre el reto o quieres compartir el enlace de tu solución, la sección de contribuciones de la plataforma es el lugar indicado.

¿Cuál fue la decisión técnica más difícil de tu solución? Cuéntame en los comentarios cómo la resolviste.