La prueba técnica de Angular consiste en construir una aplicación de tareas (todo list) que cumpla con nueve funcionalidades específicas, validadas mediante pruebas end to end. El objetivo no es lucir HTML ni CSS, sino demostrar tu dominio de Angular en componentes, estado, rutas y persistencia.

¿Cómo está estructurado el código inicial del proyecto?

El repositorio entrega una aplicación Angular con una página home lista para trabajar. Todos los estilos viven en el archivo styles, y la recomendación es no tocarlos.

¿La razón? Las pruebas end to end inspeccionan elementos por clases específicas. Por ejemplo, buscan el input con la clase new-todo. Si renombras esa clase, la prueba falla aunque tu lógica sea perfecta.

La aplicación inicial llega cargada en un solo componente, con secciones del header, las vistas de una tarea (normal, completada y edición) y el footer. Aquí entra una habilidad clave: separación de responsabilidades. En vez de dejar todo en un componente monolítico, divide la app en componentes pequeños como header, footer y tarea individual.

¿Puedo modificar los estilos del proyecto? No conviene. Las pruebas end to end dependen de clases específicas en el HTML. Cambiar estilos o nombres de clases hará que las pruebas fallen.

¿Cuáles son las funcionalidades que debes desarrollar?

Son nueve requerimientos en total. Cada uno se valida con una prueba automatizada, así que cumplirlos al pie de la letra es lo que define si pasas.

¿Cómo manejar la visibilidad y la creación de tareas?

La primera funcionalidad es ocultar las secciones main y footer cuando no hay tareas. Si la lista está vacía, solo se muestra el input de captura.

La segunda es crear una nueva tarea, y aquí hay varios detalles:

• El input debe iniciar en autofocus al cargar la aplicación.
• La tecla enter dispara el guardado de la tarea.
• Debes validar que el texto no tenga espacios al inicio ni al final. Espacios intermedios sí están permitidos.

Esa validación de espacios la cubre una prueba específica, así que conviene aplicar trim() antes de guardar.

¿Qué interacciones debe soportar cada tarea?

La tercera funcionalidad cubre las interacciones por tarea:

• El checkbox actualiza el estado a true cuando se completa y a false cuando se desmarca.
• El doble clic sobre la tarea activa el modo edición.
• En modo edición desaparecen el label, el checkbox y el botón de eliminar, y aparece un input editable.
• Enter confirma la edición; escape la cancela y sale del modo edición.
• En hover sobre la tarea se muestra el botón de eliminar.

En la edición también aplica la regla de no permitir espacios al inicio ni al final.

¿Qué hace la tecla escape en el modo edición? Sale del modo edición sin guardar los cambios y devuelve la tarea a su estado anterior.

¿Cómo funciona el contador, el botón de limpiar y la persistencia?

Estas tres piezas viven en el footer y en la capa de almacenamiento de la app.

¿Qué reglas sigue el contador de tareas pendientes?

El contador muestra solo las tareas pendientes, no el total. Si tienes cinco tareas y dos están completadas, el contador marca tres.

La pluralización importa y se evalúa:

• 0 items.
• 1 item (sin la s).
• 2 items, 3 items y en adelante con s.

Manejar bien el singular y el plural es un detalle pequeño que muchas apps reales exigen y que aquí se valida con prueba.

¿Qué hace el botón de limpiar tareas?

Elimina únicamente las tareas completadas. Cuidado con esto: no borra todas las tareas, solo las marcadas como hechas. Las pendientes permanecen intactas.

¿Cómo implementar la persistencia con local storage?

La persistencia significa que al recargar la página, las tareas siguen ahí. Para lograrlo usa local storage.

La key debe llamarse exactamente mydave-angular, en minúsculas y con el guion. Las pruebas end to end leen ese key específico para verificar que el estado se guardó. Si usas otro nombre, la prueba falla aunque la persistencia funcione.

¿Por qué importa el nombre exacto de la key en local storage? Porque las pruebas automatizadas inspeccionan ese identificador para validar la persistencia. Cualquier variación, incluso en mayúsculas o guiones, rompe la verificación.

¿Cómo configurar los filtros y el routing en Angular?

Los filtros del footer (all, pending, completed) deben funcionar como rutas reales de Angular. Hacer clic en pending tiene que llevarte a /pending y renderizar solo las tareas no completadas.

Lo mismo aplica para /completed, que muestra las terminadas, y /all, que muestra todas. Si Angular no atiende esos patterns, la vista queda en blanco y la prueba falla.

El renderizado debe responder al estado real de las tareas, así que el filtro vive conectado al store o servicio que las gestiona.

¿Qué bonus suma puntos en la entrega?

Desplegar la aplicación es un bonus opcional. No es requisito, porque la evaluación principal son las pruebas de integración que pasen. Aun así, publicarla cuenta a favor.

Opciones recomendadas:

• GitHub Pages.
• Netlify.
• Vercel.
• Firebase Hosting.

Un link en producción demuestra que sabes cerrar el ciclo completo, desde el código hasta el despliegue.

¿Cómo dividirías tú esta aplicación en componentes? Cuéntame en los comentarios cómo planeas separar las responsabilidades antes de empezar a codear.