Probar un sistema de correo construido en Kotlin significa validar cada opción del menú con casos reales: login, envío, recepción, mover entre carpetas, marcar como leído y eliminar. Esta guía recorre ese flujo de pruebas funcionales para que cualquier persona aprendiendo programación orientada a objetos en Kotlin entienda cómo verificar que su proyecto funciona de extremo a extremo.
Cómo valido el login y el menú principal en Kotlin
Antes de probar cualquier funcionalidad, necesitas autenticarte. El menú aparece justo después del proceso de login, lo que confirma que la validación de usuario y contraseña se ejecuta correctamente.
En la prueba usamos el usuario JuanDroidDev con la clave 1234. El sistema imprime los datos del usuario y muestra el menú de opciones, señal de que el flujo de autenticación está enlazado con la siguiente sección de la aplicación [00:20].
¿Por qué el menú se muestra después del login? Porque el flujo controla que solo un usuario autenticado acceda a las opciones de correo. Es una buena práctica de control de acceso.
Cómo pruebo el envío de correos y verifico la carpeta sent
La opción uno del menú permite enviar un correo. Para validarla, llenamos los campos destinatario, asunto y cuerpo, y luego revisamos que el correo aparezca en la carpeta de enviados.
Durante la prueba se envió un correo a email@email.com con el asunto reunión del martes. Al listar la carpeta sent, el correo apareció con su owner, destinatario, asunto, cuerpo, carpeta asignada y estado de lectura [01:30].
Un detalle interesante surgió aquí: faltaba un mensaje de confirmación tipo correo enviado al final del proceso. Detectar este tipo de mejoras en pruebas manuales es parte del trabajo real de un desarrollador, porque la user experience importa tanto como la lógica.
Qué información debe mostrar un correo listado
Al listar correos, cada elemento debe incluir datos suficientes para identificarlo sin abrirlo:
- Owner o propietario del correo.
- Nombre de usuario del remitente.
- Destinatario del mensaje.
- Subject o asunto.
- Cuerpo del correo.
- Carpeta a la que pertenece.
- Estado leído o no leído.
Esta estructura facilita filtrar y mover correos sin perder contexto.
Cómo simulo recibir un correo y muevo mensajes entre carpetas
La opción seis del menú simula la recepción de un correo en el inbox. Aquí ocurrió un error revelador: el correo simulado terminó en la carpeta sent en lugar de inbox porque el método estaba mal asignado [03:00].
Este tipo de bugs son comunes cuando confundes operaciones similares. La opción uno enviaba (sent) y la opción seis debía recibir (receive email), pero ambas estaban apuntando al mismo destino. Detectarlo en pruebas evita propagar el error a producción.
¿Cómo muevo un correo de una carpeta a otra? Usa la opción cuatro, proporciona el ID del correo y el nombre de la carpeta destino. El sistema confirma con un mensaje de correo movido.
La solución fue aprovechar el error para probar la opción cuatro: mover el correo desde sent hacia inbox usando el ID del mensaje. Funcionó y permitió validar dos funcionalidades con una sola prueba.
Cómo marco un correo como leído y lo elimino en Kotlin
La opción tres marca un correo como leído. Antes de ejecutarla, el correo aparecía con estado no leído al listar el inbox. Después de aplicar la opción tres con el ID correspondiente, el estado cambió a leído [04:30].
La opción que elimina correos cierra el ciclo de pruebas. Al proporcionar el mismo ID y listar nuevamente el inbox, la carpeta queda vacía, confirmando que el método de eliminación funciona.
¿Qué identifica de forma única a un correo? Su ID. Es el dato que usas para mover, marcar como leído o eliminar mensajes sin ambigüedad.
Qué conceptos de Kotlin pusiste en práctica en este curso
Este recorrido de pruebas integra los pilares del lenguaje que viste en clases anteriores:
- Creación de variables para almacenar datos de usuario y correos.
- Control de flujo con condicionales para validar el menú.
- Loops para listar correos y carpetas.
- Programación orientada a objetos para modelar usuarios, correos y carpetas.
Quedan componentes avanzados que no se usaron aquí, como sealed classes y sealed interfaces, muy comunes en desarrollo backend y mobile. Ese es el siguiente reto si quieres profundizar en Kotlin aplicado a proyectos reales [05:30].
¿Detectaste algún bug similar al del receive email mientras hacías tus pruebas? Cuéntalo en los comentarios y comparte cómo lo resolviste.