4.5Pruebas automáticas y calidad
Lo esencial en 30 segundos
- Tres niveles de verificación: las pruebas unitarias (¿un procedimiento o una clase da el resultado correcto? — el más rentable porque apunta a una regla de negocio), las pruebas de interfaz (reproducir un escenario grabado: abrir, introducir, validar, comprobar) y la auditoría del proyecto.
- El principal interés de las pruebas automáticas no es encontrar errores hoy, sino detectar las REGRESIONES mañana: volver a probar toda la aplicación a mano es imposible, así que no se hace — y las regresiones llegan a producción.
- Buenas prácticas: empezar por el núcleo de negocio (cálculos, reglas críticas), probar los casos límite (cero, valores vacíos, cambios de año), escribir una prueba por cada error corregido — y mantener las pruebas al día, porque unas pruebas obsoletas ignoradas son peores que no tener pruebas.
Minicaso continuo — Yacine asegura los cálculos de su comercio
Yacine, desarrollador WinDev en una pyme de comercio de material eléctrico en Orán, acaba de corregir un error en el cálculo de descuentos: un cliente lo detectó tres meses más tarde en su facturación. Decide no conformarse nunca más con «parece que funciona». Primero escribe pruebas unitarias sobre el núcleo de negocio: el cálculo del IVA sobre el catálogo eléctrico, los descuentos, los vencimientos. Prueba sistemáticamente los casos límite — tipo a cero, importe negativo, fecha de cambio de año — porque ahí se esconden los errores. Después graba algunos escenarios de interfaz sobre el recorrido crítico (introducción de un pedido de principio a fin) para detectar regresiones. Y se impone una regla: con cada error corregido, escribe una prueba que lo reproduzca, para que no vuelva nunca. Anota el verdadero beneficio, el más subestimado: la confianza para modificar el código sin miedo. Lo completa con la revisión de código y los comentarios de los usuarios: la calidad va más allá de las pruebas.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el guion y el reto de 48 h de la sección 4.5.
1. Tres niveles de verificación
La calidad de una aplicación no se decreta: se construye y se verifica. WinDev distingue varios enfoques. (1) Las pruebas unitarias: comprobar que un procedimiento o una clase da el resultado correcto para unas entradas dadas (¿el cálculo de IVA devuelve el valor correcto? ¿y con un tipo a cero? ¿y con un importe negativo?). Es la prueba más rentable, porque apunta precisamente a una regla de negocio. (2) Las pruebas de interfaz (IHM): reproducir automáticamente un escenario de uso (abrir una ventana, introducir, validar, comprobar el resultado) — WinDev permite grabar estos escenarios. (3) La auditoría y las herramientas de análisis del proyecto, que señalan anomalías y puntos de mejora.
2. Las pruebas automáticas lo cambian todo
¿Por qué las pruebas automáticas lo cambian todo? Porque son reproducibles a voluntad. Su beneficio principal no es encontrar errores hoy, sino detectar las regresiones mañana: cuando se modifica una regla o se corrige un defecto, ¿cómo saber que no se ha roto nada en otro sitio? Volver a probar manualmente toda la aplicación es imposible en la práctica — por tanto no se hace, y las regresiones llegan a producción. Las pruebas automáticas hacen ese trabajo en unos minutos. También aportan, a menudo de forma subestimada, la confianza para modificar el código: sin pruebas se acumulan parches, con pruebas se refactoriza con tranquilidad.
3. Buenas prácticas y calidad en sentido amplio
Algunas buenas prácticas. (1) Empiece por el núcleo de negocio (cálculos, reglas críticas) en lugar de buscar una cobertura total. (2) Pruebe los casos límite (cero, valores vacíos, valores extremos, fechas de cambio de año): ahí se esconden los errores. (3) Escriba una prueba con cada error corregido para garantizar que no volverá. (4) Mantenga las pruebas al día: unas pruebas obsoletas que se ignoran son peores que no tener pruebas. Por último, la calidad va más allá de las pruebas: la revisión de código, la documentación, las convenciones y los comentarios de los usuarios también forman parte de ella.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Una prueba unitaria y sus casos límite
Apuntar a una regla de negocio, como hace Yacine:
// Test unitaire du calcul de TVA du catalogue electrique
PROCEDURE Test_TVA()
sTTC est un numerique = CalculeTTC(1000, 19)
SI sTTC <> 1190 ALORS
Erreur("TVA attendue 1190, obtenue : " + sTTC)
FIN
// Cas limites : taux a zero et montant negatif
SI CalculeTTC(0, 19) <> 0 ALORS
Erreur("Cas limite zero non gere")
FINLectura: una prueba unitaria verifica un procedimiento para unas entradas dadas, incluidos los casos límite donde se esconden los errores.
Lección: esta prueba se convierte en el guardián que detecta una regresión si la regla se modifica más adelante.
Vocabulario de la sección
- Prueba unitaria
- Comprobar que un procedimiento o una clase da el resultado correcto para unas entradas dadas — la prueba más rentable, porque apunta a una regla de negocio.
Ejemplo sencillo: Yacine prueba el cálculo de IVA del catálogo eléctrico.
Lo que no es: hacer clic a mano en la interfaz para «ver si funciona».
Reflejo: verificar una regla → la prueba unitaria.
- Prueba de interfaz (IHM)
- Reproducir automáticamente un escenario de uso (abrir, introducir, validar, comprobar); WinDev permite grabar estos escenarios.
Ejemplo sencillo: Yacine graba la introducción de un pedido de principio a fin.
Lo que no es: una prueba que solo verifica cálculos aislados.
Reflejo: reproducir un recorrido → el escenario de interfaz.
- Regresión
- Un defecto introducido por una modificación en una parte que funcionaba — el riesgo principal en mantenimiento, y la razón de ser de las pruebas automáticas.
Ejemplo sencillo: La corrección de los descuentos de Yacine no debe romper los totales.
Lo que no es: un error presente desde la primera versión.
Reflejo: proteger lo existente → contra las regresiones.
- Casos límite
- Cero, valores vacíos, valores extremos, cambios de año, cadenas muy largas, caracteres especiales: donde se esconden la mayoría de los errores.
Ejemplo sencillo: Yacine prueba un descuento del 0 % y un importe negativo.
Lo que no es: probar solo valores «normales», bien redondos.
Reflejo: encontrar los errores → probar los casos límite.
- Calidad en sentido amplio
- Más allá de las pruebas: la revisión de código, la documentación, las convenciones de equipo y los comentarios de los usuarios también forman parte del enfoque de calidad.
Ejemplo sencillo: Yacine hace revisar su código y anota los comentarios de los comerciales.
Lo que no es: creer que las pruebas por sí solas bastan para la calidad.
Reflejo: enfoque completo → la calidad en sentido amplio.
En la práctica — En la práctica — Implantar pruebas
- Empiece por pruebas unitarias sobre el núcleo de negocio: los cálculos y reglas críticas (IVA, descuentos, vencimientos) — la mejor relación esfuerzo/beneficio, como Yacine.
- Pruebe sistemáticamente los casos límite: cero, valores vacíos, importes negativos, fechas de cambio de año, cadenas muy largas.
- Grabe algunos escenarios de interfaz sobre los recorridos más críticos (introducción de un pedido de principio a fin) para detectar regresiones.
- Con cada error corregido, escriba una prueba que lo reproduzca: garantiza que no volverá nunca. Y mantenga sus pruebas al día.
Guion paso a paso — probar como Yacine (5 min)
1) Identifique el núcleo de negocio de su aplicación (cálculos, reglas críticas). 2) Escriba una prueba unitaria por regla (IVA, descuentos, vencimientos) que compruebe un resultado conocido. 3) Añada los casos límite: cero, valores vacíos, importe negativo, cambio de año. 4) Grabe un escenario de interfaz sobre el recorrido de introducción de pedidos. 5) Con cada error corregido, añada una prueba que lo reproduzca. 6) Ejecute la batería de pruebas después de cada modificación y manténgala al día.
Sea selectivo: el núcleo de negocio y los casos límite aportan más; mantenga las pruebas al día, porque si no dan una falsa sensación de seguridad.
Plantilla para copiar y pegar — mi ficha de pruebas
Unitaires : une procedure/classe -> bon resultat (coeur metier)
Interface : rejouer un scenario enregistre (ouvrir, saisir, valider)
Regressions: LE risque en maintenance -> detectees en minutes
Cas limites: zero, vide, negatif, changement d'annee
Regle d'or : un test a CHAQUE bug corrige
Tenue : tests obsoletes ignores = pires que pas de tests
Au-dela : revue de code, documentation, conventions, retours usersPrueba unitaria de IVA
Yacine comprueba que CalculeTTC(1000, 19) devuelve 1190.
Caso límite
Yacine prueba un descuento del 0 %, un importe negativo y un cambio de año.
Escenario de interfaz
Yacine graba la introducción completa de un pedido para reproducirla.
Prueba tras la corrección
Yacine escribe una prueba que reproduce el error de descuento para que no vuelva nunca.
✓ Buenas prácticas
- Empezar por el núcleo de negocio, no por una cobertura total.
- Probar los casos límite y escribir una prueba con cada error corregido.
- Mantener las pruebas al día y completarlas con la revisión de código.
✗ Errores frecuentes
- Buscar el 100 % de cobertura en una aplicación pequeña.
- Dejar pruebas obsoletas que todo el mundo ignora.
- Creer que probar la visualización verifica los cálculos.
Puntos clave
- Tres niveles: pruebas unitarias (rentables), escenarios de interfaz, auditoría del proyecto.
- El objetivo de las pruebas automáticas es detectar las regresiones, no solo los errores del día.
- Buenas prácticas: núcleo de negocio, casos límite, una prueba por error corregido.
- ⚠️ Mantener las pruebas al día; la calidad incluye revisión de código, documentación y comentarios de los usuarios.
Reto 48 h — aplícalo mañana
Como Yacine, elija una regla de negocio de su aplicación (un cálculo de IVA, de descuento o de vencimiento) y escriba al menos tres pruebas unitarias: un caso «normal» y dos casos límite (cero, valor negativo, cambio de año). Grabe después un escenario de interfaz sobre un recorrido crítico. Tome el último error corregido y escriba la prueba que lo reproduce. Ejecute la batería y anote el tiempo ganado: esos pocos minutos sustituyen a una relectura manual imposible.
- Escribo pruebas unitarias centradas en el núcleo de negocio.
- Pruebo los casos límite y grabo escenarios de interfaz.
- Añado una prueba con cada error corregido y mantengo mis pruebas al día.
Preguntas frecuentes
¿Merecen la pena las pruebas automáticas en un proyecto pequeño?
Sí, pero de forma selectiva: no intente probarlo todo, céntrese en el núcleo de negocio (cálculos y reglas críticas) y en los errores ya encontrados. Unas pocas pruebas bien elegidas aportan mucho; una cobertura exhaustiva costaría más de lo que aportaría en un proyecto pequeño. Una aplicación de gestión vive mucho tiempo y evoluciona: el verdadero coste no es escribir la prueba, sino no tenerla cuando una modificación rompe silenciosamente un cálculo y un cliente lo descubre tres meses más tarde. Las pruebas también dan confianza para modificar y sirven de documentación.
¿Cómo saber si mi aplicación es de buena calidad?
Observando varias dimensiones objetivas: hace lo que debe (exactitud), resiste los imprevistos (robustez), se usa con eficacia (ergonomía), sigue siendo rápida con volúmenes reales (rendimiento) y puede evolucionar sin dolor (mantenibilidad) — todo ello validado por los usuarios reales. La exactitud es la más importante: en gestión, un total falso o un stock incoherente son defectos graves, tanto más peligrosos cuanto que no provocan ningún error visible. Complete con la seguridad y la desplegabilidad, y escuche las señales de alerta (miedo a modificar, errores recurrentes, regresiones).
¿Cuál es el principal interés de las pruebas automáticas?