FishMind empezó como una idea pequeña: un quiz de Android para saber qué tipo de pescador es cada uno. No voy a repetir aquí la presentación, porque ya la hice en su momento. Lo que quiero contar es otra cosa: qué se aprende de verdad al construir algo que parece trivial y que, en la práctica, no lo es tanto.
Un quiz suena a lo más simple que se puede programar. Preguntas, respuestas, una puntuación al final. Y sí, la primera versión se puede montar en una tarde. El problema aparece después, cuando intentas que ese quiz se comporte bien en condiciones reales: pantallas giradas, procesos interrumpidos, respuestas ambiguas, usuarios que cierran la app a mitad de una pregunta.
Por qué un quiz parece fácil y no lo es
La lógica de negocio de un quiz es mínima. El reto no está ahí, está en todo lo que rodea esa lógica: navegación entre preguntas, persistencia del progreso, gestión de estados de carga y, sobre todo, decidir qué pasa cuando algo no sale como estaba previsto.
Cuando diseñé FishMind pensé primero en el resultado final —el tipo de pescador que se le asigna a cada persona— y dejé para después el recorrido intermedio. Fue un error de orden. El recorrido intermedio es donde vive casi todo el código, y donde aparecen casi todos los bugs.
El banco de preguntas es el verdadero problema
Al principio tenía las preguntas escritas directamente en el código, como listas de texto dentro de la actividad. Funcionaba, pero cada cambio de redacción implicaba recompilar la app entera. En cuanto quise ajustar el tono de una pregunta o corregir una opción de respuesta, entendí que necesitaba separar el contenido de la lógica.
Terminé moviendo las preguntas a un modelo de datos independiente, cargado desde un recurso estructurado en lugar de cadenas sueltas en el código. Esto no es ninguna novedad de arquitectura, es de manual. Pero cuando empiezas por lo pequeño, es fácil saltarse ese paso hasta que duele.
Lo que sí me sorprendió es cuánto tiempo se va en decidir cómo puntúa cada respuesta. No todas las preguntas deben pesar igual, y algunas combinaciones de respuestas no encajan bien en ningún perfil. Ese ajuste fue más de diseño de contenido que de programación, y lo subestimé completamente al planificar.
Estados de la interfaz que no aparecen en el diseño
Cuando diseñas las pantallas en una herramienta de maquetación, ves la pregunta uno, la pregunta dos, la pantalla de resultado. Lo que no ves ahí son los estados intermedios: la pantalla vacía mientras carga el banco de preguntas, el estado de error si algo falla al leer ese banco, el estado de "sin conexión" si en algún momento el quiz necesita datos remotos.
En FishMind terminé con más código dedicado a gestionar esos estados que a la lógica del propio quiz. Y eso no es un despilfarro: es la parte que hace que la app se sienta terminada en lugar de improvisada. Un quiz que se rompe en silencio cuando gira la pantalla no es un quiz pequeño con un fallo pequeño, es una app que no inspira confianza.
Cómo pruebo la lógica de puntuación
Aquí sí apliqué algo que ya tenía asumido de otros proyectos: si la puntuación decide el resultado que ve la persona, esa lógica necesita pruebas unitarias, no solo pruebas manuales tocando la pantalla.
Escribí un conjunto de combinaciones de respuestas conocidas, con el resultado esperado para cada una, y comprobé que el algoritmo de puntuación las resolvía todas igual tras cada cambio. No es un sistema sofisticado. Es simplemente no fiarme de mi propia memoria sobre cómo se comportaba el código la semana anterior.
Esto me ahorró al menos un par de regresiones silenciosas cuando reordené el peso de algunas preguntas. Sin esas pruebas, probablemente no las habría detectado hasta después de publicar un cambio.
Qué me falta antes de darlo por terminado
FishMind todavía está en fase de validación. No está publicado en Google Play y no voy a afirmar que lo esté. Antes de dar ese paso quiero comprobar cosas muy concretas: que el flujo completo funciona igual en distintos tamaños de pantalla, que el texto de las preguntas se entiende sin ambigüedad para gente que no conoce el argot de pesca, y que el resultado final no se siente arbitrario.
Esa validación pendiente no es un detalle menor que se resuelve al final. Es la parte que decide si el quiz merece salir de mi propio móvil de pruebas.
Errores que cometí al principio
El principal fue tratar el contenido como si fuera código de usar y tirar. Cambié preguntas directamente en el layout más de una vez, sin pensar en cómo eso afectaría a las traducciones futuras o a la reutilización del mismo motor para otro quiz. El segundo fue no medir bien cuánto tiempo iba a llevar el trabajo de contenido frente al trabajo de código: acabé dedicando más horas a redactar y calibrar preguntas que a programar la pantalla de resultados.
Conclusión
Un quiz Android pequeño no enseña gran cosa sobre pesca, pero enseña bastante sobre cómo estructurar contenido, cómo separar datos de lógica y cómo no fiarte de las pruebas manuales cuando hay una puntuación de por medio. FishMind sigue sin validar del todo, y prefiero decirlo así en lugar de presentarlo como algo cerrado que no lo es. Si te interesa cómo aplico pruebas antes de tocar partes sensibles de una app, lo cuento con más detalle en qué pruebas hago antes de tocar datos sensibles.