Verificar lo que devuelve5 minFondation

Probado, o simplemente aún no refutado

Probado significa que un comando concreto se ha ejecutado y que su salida ha sido leída; aún no refutado significa solo que nada ha detectado un problema hasta ahora, una afirmación mucho más débil.

Una verificación de tipos prueba que no se ha detectado ninguna incoherencia de tipo en los archivos examinados, no que el código compile ni que se ejecute: la resolución de módulos, el empaquetado y las dependencias nativas quedan fuera de su alcance. Una batería de pruebas prueba que los caminos que ejercita se comportan como está escrito. Una vista previa sin interfaz, una ejecución simulada sin que ningún humano toque una pantalla real, prueba que los componentes se montan sin fallar. Nada de esto prueba que un producto funcione de verdad para una persona que sostiene un aparato real.

Dos palabras que se confunden bajo una sola etiqueta

La mayoría de los cursos sobre pruebas mezclan dos estados muy distintos bajo la palabra probado. La distinción honesta separa dos afirmaciones. Probado significa que has ejecutado un comando concreto y que puedes citar su salida. Aún no refutado significa que nada ha detectado un problema hasta ahora, lo cual es una afirmación mucho más débil: una vista previa en verde o una ausencia de error en consola significa solo que las verificaciones realizadas no han revelado un defecto por casualidad, no que no exista ningún defecto.

Un formato que parece correcto ilustra bien la diferencia. Una expresión regular de número de teléfono puede ejecutarse y su salida citarse: eso está probado, en sentido estricto.

$ node -e "console.log(/^\+33[1-9][0-9]{8}$/.test('+33199999999'))"
true

Lo que esta línea prueba se detiene ahí: la cadena tiene la forma esperada. No prueba nada sobre el número en sí, que sigue siendo solo aún no refutado mientras nadie haya marcado la línea de verdad.

Señales en verde, y aun así defectos

Véase la figura: se entregaron lotes con todas las señales automatizadas en verde, verificaciones de tipos superadas, cobertura completa, vista previa sin interfaz limpia. La persona que realmente instaló la aplicación en un aparato real encontró problemas en pocos minutos, ninguno de los cuales había sido detectado por un control: una lentitud que solo aparece bajo una pantalla táctil real y una presión de memoria real, un parámetro configurado para el hardware equivocado, y un botón de contacto que marcaba una línea fija que una aplicación de mensajería ordinaria no podría alcanzar. Cada uno de estos defectos era invisible por construcción para una ejecución sin interfaz, que no tiene ni dedo, ni pantalla, ni línea telefónica.

El remedio está en el informe, no en más automatización

Añadir verificaciones automatizadas no repara esta clase de defecto, que resiste a la automatización por naturaleza. El remedio es la honestidad del informe de estado, un tema ya planteado a propósito de lo que una verificación muy rigurosa no puede ver. Antes de declarar un trabajo terminado, escribe lo que se ha probado, con el comando y la línea de salida citados, y lo que sigue siendo solo aún no refutado, como una vista previa limpia o una consola silenciosa. Nombra de antemano lo que solo puede decidirse en un aparato real o por un usuario real, para que nadie confunda ese silencio con un veredicto.

Figure 1

Lo que cada control prueba, y lo que no puede probar

Verificación automatizada	Lo que realmente prueba	Lo que no puede probar
La verificación de tipos se supera	Ninguna incoherencia de tipo detectada entre los archivos resueltos	La sintaxis de los archivos fuera del alcance tipado, la ejecución real, el comportamiento en un aparato real
El lint se supera	El código respeta las reglas de estilo y los patrones peligrosos que el linter conoce	La ausencia de error de tipo, el comportamiento real en un aparato real
Vista previa sin interfaz, cero errores de consola	Los componentes se montan sin fallar	La pantalla es legible bajo un dedo real, la animación parece fluida
La batería de pruebas completa está en verde	Los caminos codificados se comportan como está escrito	La funcionalidad hace lo que el usuario realmente necesitaba
Un campo de número de teléfono coincide con el formato esperado	La cadena tiene la forma correcta	El número alcanza una línea activa en ese canal real

Cinco controles distintos, cada uno con su propio límite, enumerados uno al lado del otro en lugar de fundidos en una sola línea que ocultaría sus garantías distintas.

Figure 2

Señales en verde, defectos encontrados solo con el uso real

7lotes entregados

Lotes entregados con verificación de tipos, cobertura de pruebas y vista previa sin interfaz todos en verde, donde un uso real en un aparato real encontró defectos de todos modos

p20l13, 2026

Una cifra fechada y con fuente aísla este hecho en un solo lugar, para que solo caduque una vez si el lote citado cambia de naturaleza.

Calíbralo tú mismo

Una pantalla de aplicación es renderizada por una herramienta de vista previa automatizada que se ejecuta en el servidor de integración continua. Esta vista previa se apoya en un motor de renderizado que simula la estructura de los componentes directamente en memoria, en ese mismo servidor. El renderizado termina, sin que la consola muestre ningún error.

Escribe en una frase lo que este resultado establece, y en una frase lo que no establece.

Tu respuesta, antes de ver la corrección

Lo que hay que recordar

Probado designa un comando concreto que se ha ejecutado y cuya salida ha sido citada; aún no refutado designa solo la ausencia de problemas constatada hasta ahora, una afirmación notablemente más débil.
Una vista previa sin interfaz prueba que los componentes se montan sin fallar, nunca que una pantalla sigue siendo legible bajo un dedo real o que un número de teléfono es localizable.
Varios lotes entregados enteramente en verde fallaron sin embargo en la instalación real, véase la figura, en una lentitud, un parámetro de hardware equivocado y un botón que marcaba una línea inalcanzable.
Antes de entregar, separa por escrito lo que está probado de lo que está solo aún no refutado, y nombra lo que solo un aparato real puede decidir.

Hazlo ahora

Retoma la última afirmación de éxito que has hecho sobre tu propio trabajo y sepárala en dos listas: lo que está probado, con el comando exacto y la línea de salida citados, y lo que sigue siendo solo aún no refutado, como una ausencia de error constatada.