Software Crafters® 2025 | Creado con 🖤 para elevar el nivel de la conversación sobre programación en español | Legal
Property Based Testing , WYSIATI y la ley de los pequeños números
Casino de Monte Carlo. 13 de diciembre de 1913. Esa noche, en la ruleta, la bola cayó 26 veces seguidas en el negro.
Miguel A. Gómez · Seguir2 min read · 7 Abr 2023
Casino de Monte Carlo.
13 de diciembre de 1913.
Esa noche, en la ruleta, la bola cayó 26 veces seguidas en el negro.
Cuando se encadenaron 15 seguidos los jugadores asumieron que en un sitio de tanto prestigio la ruleta no podía estar trucada.
Empezaron a apostar cada vez más dinero al rojo.
Creían que ya tocaba…
“Todo al rojo”
Seguro que eso fue lo que pensó más de uno.
Pero la realidad es que entre la ronda 16 y la 26 los apostantes perdieron un montón de pasta.
Mucha.
Y no, la ruleta no estaba trucada.
Lo que sucedió es que su cerebro les jugó una mala pasada.
Por dos sesgos cognitivos.
Dos.
El primero es la llamada “Ley de los pequeños números”.
Esta ley describe nuestra tendencia a generalizar a partir de un número pequeño de observaciones.
En este caso, después de ver salir el negro unas pocas veces, los jugadores empezaron a creer que había una tendencia emergente y supusieron que pronto tendría que revertirse.
Ignoraron el hecho de que cada tirada de la ruleta es un evento independiente que no está influenciado por lo que ocurre en las rondas anteriores.
La ley de los pequeños números los llevó a interpretar estas pocas rondas de negro como un patrón significativo y a esperar una inminente "racha roja".
Pero lo único que se puso en rojo fue su cuenta corriente.
El segundo sesgo cognitivo es conocido como “WYSIATI” acrónimo de "What You See Is All There Is".
Vamos, “Lo que vemos es todo lo que hay”.
Este sesgo, descrito por Daniel Kahneman, nos lleva a formar conclusiones basadas sólo en la información que tenemos a mano.
Sin considerar lo que podríamos estar pasando por alto.
Dejando de lado lo que sabemos que no sabemos…
… y lo que no sabemos que no sabemos, también.
Verás.
Cuando escribimos tests estos dos sesgos suceden constantemente.
Sobre todo cuando estamos probando elementos en los que validar el happy path y algunos casos edge simplemente no es suficiente.
Elementos en los que descubrir el número de casos a testar no es trivial.
Y es aquí donde el Property Based Testing nos puede ayudar.
Un tipo de testing que en lugar de centrarse en casos de prueba individuales, se enfoca en las propiedades que un sistema debe cumplir.
