Todo empezó con un correo de CABSA tras la entrevista: una pequeña prueba técnica para ver cómo desarrollamos una solución y escribimos código. Nada de algoritmos imposibles ni maratones de programación — solo una API sencilla, un esqueleto de Spring Boot ya arrancable, y una recomendación clara: "valoraremos más la estructura de código y limpieza del mismo que la funcionalidad en sí".
El reto
El enunciado pedía tres cosas muy concretas:
- Devolver un listado de animales en JSON junto con lo que comen.
- Poder buscar animales por nombre o por lo que comen.
- Poder crear un nuevo tipo de comida.
Con eso en mente, y sabiendo que el foco estaba en la calidad del código más que en la cantidad de funcionalidad, nos pusimos manos a la obra sobre el esqueleto proporcionado.
Construir sobre lo que ya había
El esqueleto ya traía una arquitectura por capas esbozada. Completamos esa
estructura de forma coherente: un JungleController con los tres
endpoints REST, una capa de servicio (AnimalService /
AnimalServiceImpl) con la lógica de negocio, repositorios JPA para
animales y comida, y un DTO (AnimalDto) para no exponer
directamente el modelo persistido en las respuestas. Todas las respuestas de la
API quedaron unificadas bajo un mismo envoltorio, ApiResponse, con
estado, mensaje y datos.
Parar a limpiar antes de dar la prueba por terminada
Con la funcionalidad lista, tocaba hacer lo que realmente iban a valorar: revisar el código con ojo crítico. Dos cosas llamaron la atención:
-
El método de búsqueda por nombre y/o comida tenía tres bloques casi
idénticos, repitiendo una y otra vez el mismo patrón de "buscar, comprobar
si es nulo, construir la respuesta". Lo reescribimos en una única lógica,
mucho más corta y fácil de leer. De paso, esa simplificación destapó y
corrigió un
NullPointerExceptionsilencioso que ocurría al buscar por nombre y comida a la vez cuando solo uno de los dos existía en base de datos. - Encontramos una pequeña inconsistencia entre las dos entidades: la comida generaba su id automáticamente, pero el animal no, pese a que la columna en base de datos era igualmente autoincremental. Se alineó el criterio entre ambas.
Verificarlo con tests
Una vez cerrada la limpieza, tocaba demostrar —no solo asumir— que el comportamiento seguía siendo correcto. Añadimos una batería de tests unitarios sobre la capa de servicio con JUnit 5 y Mockito, mockeando los repositorios para no depender de una base de datos real. Cubrimos el listado completo, la búsqueda por nombre, por comida y por ambos a la vez, los casos de "no encontrado", y muy especialmente el caso de regresión del error que acabábamos de corregir, para asegurarnos de que no volvería a aparecer.
Dejarlo todo documentado
Por último, separamos claramente el enunciado de la solución: un
README.md que recoge fielmente lo que se pedía en la prueba, y un
SOLUTION.md que explica cómo se resolvió — arquitectura,
endpoints, decisiones de diseño y cómo poner en marcha tanto la aplicación
como los tests.
El resultado
Una API pequeña, ordenada y probada, que cumple lo que pedía CABSA sin más complejidad de la necesaria — que, al final, era justo el objetivo de la prueba.