Estamos construyendo SeeYouAT, un sistema de citas para negocios pequeños que atienden en local, a domicilio o por videollamada. Antes de cerrar la semana revisamos todo a fondo y nos encontramos algo incómodo: varias pruebas automáticas estaban en verde, pero no comprobaban nada.
El problema
- Una prueba tenía que verificar que, si el negocio no atiende a domicilio, no se buscan direcciones en el mapa. Pasaba, pero por otra razón: los datos de ejemplo no tenían ninguna cita, así que la regla nunca llegaba a ejecutarse.
- Otra prueba, sobre el cambio de zona horaria, usaba una fecha fija. Cuando esa fecha quedara en el pasado, seguiría en verde sin probar nada.
- Una tercera fallaba solo los viernes y sábados, porque daba por hecho que mañana siempre hay horario.
Qué probamos Nos pusimos una regla: antes de aceptar una prueba, rompemos el código a propósito y comprobamos que falla. Si sigue en verde, no sirve.
Qué funcionó
- Probar las dos caras de cada regla. Con la atención a domicilio apagada, no se busca la dirección. Con la atención a domicilio encendida, sí se busca.
- Dejar de usar fechas fijas y palabras como hoy o mañana. Cada prueba calcula la situación que necesita, por ejemplo el próximo cambio de horario de verano.
- Al revisar ese caso encontramos algo real: una cita que caía justo en el cambio de horario podía terminar antes de empezar. Ahora el inicio y el fin se mueven lo mismo.
Qué no funcionó Confiar en que una prueba antigua seguía siendo válida solo porque nunca había fallado.
También aprendimos algo del producto: el registro inicial pedía demasiado. Lo dejamos en 5 pasos y el resto pasó a una tarjeta de sugerencias que el dueño puede atender o descartar.
Pregunta para la comunidad: ¿cómo validan que sus pruebas prueban algo de verdad? ¿Usan mutation testing, rompen el código a mano o tienen otro método?
Lo contamos desde Tinto & Bots, donde construimos SeeYouAT en público.
Esta entrada forma parte de nuestra bitácora semanal: construimos en público y contamos lo que aprendemos.