Dos pequeñas cajas de madera juntas sobre un banco de trabajo: la izquierda montada sin orden y agrietada, la derecha construida en orden y sólida, con una mano apoyada en la caja sana

· 6 min de lectura · Actualizado el

¿Cómo comprobar una aplicación si no sabes programar?

Dos clientes reservan a la misma hora: ¿qué debe ocurrir? Este ejemplo explica para qué sirve una prueba, por qué prepararla pronto y qué puedes comprobar tú.

Imaginemos una herramienta de reservas. Dos clientes eligen la misma hora casi al mismo tiempo. El resultado esperado es fácil de explicar: solo debe confirmarse una reserva y el otro cliente debe poder elegir otra hora. Esa frase prepara una comprobación útil.

Una prueba plantea una pregunta concreta

Una prueba consiste en reproducir una situación y comparar el resultado con lo esperado. Puedes hacerla a mano, utilizando dos cuentas de prueba y datos inventados.

Una prueba automática realiza una comprobación mediante código. Se puede repetir después de un cambio para detectar ciertos problemas. Su utilidad depende de lo que compruebe realmente: un indicador verde no demuestra por sí solo que toda la aplicación funcione.

Decide el resultado correcto antes de construir

En esta reserva, hay que elegir la regla antes de intentar programarla. Si decides después, corres el riesgo de aceptar el funcionamiento obtenido simplemente porque ya existe.

Escribir pruebas antes del código forma parte de un método llamado TDD. No necesitas aprender esas siglas para pedir lo esencial: «Enséñame primero qué vamos a comprobar y qué resultado se considerará correcto».

Elige las situaciones importantes

Empieza con una acción normal y después un error frecuente. Una reserva se confirma; una hora ocupada se rechaza. Añade una regla importante: un compañero autorizado a consultar el calendario no debe poder cambiar los horarios.

Estas situaciones pueden salir de tu documento de requisitos. Ayudan a hablar de las comprobaciones sin abrir archivos de código y sin pretender cubrir todas las posibilidades.

Pregunta qué se ha probado

Cuando se anuncie que una etapa está terminada, pregunta qué situaciones se comprobaron, cuál fue el resultado y si hubo fallos. Repite tú mismo el recorrido principal en la aplicación cuando sea posible.

Si una comprobación falla, hay que entender por qué. Cambiar el resultado esperado para obtener una luz verde solo tiene sentido si la necesidad ha cambiado realmente. La razón de ese cambio debe quedar visible.

Mantén expectativas realistas

En Maestro, el método prepara comprobaciones al dividir el trabajo en tareas. Tu validación incluye revisar la necesidad descrita y el resultado que puedes observar.

Las pruebas útiles reducen el riesgo de pasar por alto errores; no demuestran que no haya defectos ni que el producto sea seguro. Para empezar, escribe tres situaciones de las que dependa tu actividad y pregunta cómo se comprobará cada una.

Leer la guía completa: crear una aplicación sin programar

Volver al diario

Toma la batuta.

Deja tu correo para probar Maestro en las primeras tandas.

La beta está abierta por invitación en macOS 13 y versiones posteriores. Deja tu email para una próxima tanda de acceso. Windows está en preparación.

La beta está disponible actualmente en macOS 13 o posterior. Tu respuesta nos ayuda a preparar otras versiones.

Tu correo solo se usa para avisarte de la apertura. Nada más, prometido.