En el mundo moderno de la ciencia y la ingeniería, los datos rara vez llegan en filas nítidas y uniformes. En su lugar, a menudo llegan como una red enredada de listas dentro de listas, donde una entrada puede contener un solo número, otra una docena, y una tercera podría faltar por completo. Los científicos utilizan herramientas informáticas especiales para organizar esta información desordenada, pero estas herramientas deben ser increíblemente robustas. Si una herramienta falla al encontrar un arreglo de datos extraño o inusual, puede corromper años de investigación o esconder descubrimientos críticos. Para asegurar que estas herramientas funcionen correctamente, los programadores escriben pruebas, pero los métodos de prueba tradicionales suelen depender de la verificación de unos pocos ejemplos específicos y preseleccionados. Este enfoque es como revisar un puente solo con una bicicleta y un sedán; puede que resista, pero no dice nada sobre cómo se comportaría bajo un camión pesado o durante un terremoto. La vasta cantidad de formas posibles en las que los datos pueden organizarse significa que los ejemplos preseleccionados pueden fácilmente pasar por alto las situaciones raras y complicadas donde el software es más propenso a fallar.

Un equipo de investigadores de la Universidad de Princeton ha desarrollado una nueva forma de probar el software que maneja estos datos complejos, específicamente una herramienta llamada Awkward Array. En lugar de alimentar al software con una lista fija de ejemplos, crearon un sistema que genera automáticamente miles de estructuras de datos únicas y aleatorias cada vez que se ejecuta. Este sistema, llamado Hypothesis-awkward, actúa como un explorador incansable que constantemente inventa combinaciones de datos nuevas y extrañas para ver si el software puede manejarlas. Al obligar al software a enfrentarse a estos escenarios impredecibles, los investigadores encontraron docenas de errores ocultos que habían pasado desapercibidos anteriormente. Su trabajo demuestra que, al permitir que las computadoras generen sus propios casos de prueba, podemos construir un software que sea mucho más confiable y capaz de manejar la realidad desordenada de los datos científicos.

Los investigadores se centraron en una biblioteca de Python conocida como Awkward Array, la cual está diseñada para almacenar datos que son anidados, de longitud variable y de tipo mixto. Imagine un archivador digital donde un cajón contiene un solo archivo, el siguiente contiene una pila de papeles, y el tercero está vacío, mientras que el contenido de los archivos mismos podría ser números, palabras o fechas. Esta flexibilidad es esencial para la ciencia moderna, pero crea una cantidad masiva de configuraciones posibles. Los investigadores señalaron que las pruebas tradicionales, que utilizan muestras predefinidas elegidas por los desarrolladores, solo pueden cubrir una fracción diminuta de estas posibilidades. Un programa podría pasar todas sus pruebas estándar y fallar completamente ante un arreglo de datos específico e inusual que ningún humano pensó en verificar. Esta limitación deja al software vulnerable a errores que solo aparecen en la práctica, causando potencialmente fallos cuando los científicos más necesitan la herramienta.

Para resolver esto, el equipo construyó una colección de estrategias que generan datos aleatorios sobre la marcha. Estas estrategias pueden crear arreglos con casi cualquier disposición posible, incluyendo listas de listas, valores faltantes y tipos de datos mixtos, todos anidados a varias profundidades. El sistema está diseñado para ser inteligente en la forma en que crea estas pruebas. Cuando una prueba falla, el sistema no solo se detiene; intenta automáticamente simplificar el ejemplo fallido, eliminando las partes innecesarias hasta encontrar la versión más pequeña y simple de los datos que aún causa el error. Este proceso ayuda a los desarrolladores a señalar exactamente dónde se está rompiendo el software. Los investigadores también se aseguraron de que el sistema no pudiera ser "engañado" por el software. Debido a que los datos se generan en el momento en que se ejecuta la prueba, el software no puede estar preprogramado para dar la respuesta correcta para un conjunto específico de entradas, un problema que puede ocurrir con las pruebas estáticas y preescritas.

El equipo puso en práctica este nuevo método de prueba en el propio software Awkward Array, sometiéndolo a un ciclo continuo de verificaciones cada vez que se actualizaba el código. Comenzaron con un pequeño conjunto de pruebas que cubría solo algunas de las funciones del software, pero los resultados fueron inmediatos y significativos. En un corto período, estas pruebas automatizadas descubrieron treinta y siete errores distintos en la biblioteca Awkワード Array. De estos, once ya han sido corregidos. Los errores variaban desde el hecho de que el software devolvía resultados incorrectos sin levantar ninguna señal de advertencia, hasta colapsar cuando encontraba casos límite específicos como listas vacías, valores faltantes en posiciones inusuales o tipos muy específicos de números. Las pruebas fueron tan efectivas que incluso encontraron un error en el propio sistema de pruebas, así como un error separado en otra biblioteca de software llamada PyArrow, que se utiliza frecuentemente junto con Awkward Array.

Los errores encontrados no eran simples fallos menores; eran problemas fundamentales que surgían de las formas complejas en que los datos pueden estructurarse. Por ejemplo, las pruebas revelaron errores en la forma en que el software convierte los datos entre diferentes formatos, como transformar listas anidadas complejas en tablas de números estándar. También encontraron problemas en la forma en que el software maneja los datos faltantes o cómo aplana capas profundas de listas en una sola línea. Muchos de estos errores solo aparecían cuando los datos tenían características específicas e inusuales, como una lista que estaba vacía, un número que era infinito o una fecha que faltaba. Debido a que el sistema de pruebas podía generar estas condiciones raras automáticamente, expuso debilidades que los probadores humanos habían pasado por alto durante años. Los investigadores encontraron que los desencadenantes más comunes de estos errores eran los casos límite: situaciones donde los datos estaban vacíos, incompletos o formateados de una manera que era técnicamente válida pero rara vez vista en la práctica.

Este enfoque representa un cambio en la forma en que se asegura la confiabilidad del software. Al alejarse de los ejemplos estáticos y preseleccionados y avanzar hacia los datos dinámicos y generados, los investigadores han demostrado que es posible explorar el vasto espacio de errores potenciales de manera mucho más exhaustiva. El sistema no solo verifica si el software funciona con los datos que se esperan; busca activamente los datos donde el software podría fallar. El éxito de este método sugiere que, a medida que el software se vuelve más complejo y maneja datos más variados, confiar en la intuición humana para adivinar cada caso de prueba posible ya no es suficiente. En su lugar, los sistemas automatizados que pueden inventar y explorar estos escenarios se están volviendo esenciales para mantener la integridad de las herramientas científicas.

Mirando hacia el futuro, los investigadores planean expandir estas capacidades aún más. Tienen la intención de desarrollar estrategias que puedan generar datos de tipos específicos, lo que haría que las pruebas fueran aún más relevantes para los científicos que utilizan estas herramientas para sus propios análisis. Actualmente, las pruebas cubren solo una pequeña parte de las funciones de Awkward Array, pero el equipo espera que, a medida que amplíen la cobertura para incluir cada característica testeable, encontrarán muchos más errores. El objetivo final es crear un entorno de pruebas tan confiable que agentes de inteligencia artificial pudieran ser confiados para reescribir grandes secciones del código interno del software, con la seguridad de que las pruebas automatizadas detectarán cualquier error introducido durante el cambio. Esta visión depende de la base sentada por el trabajo actual: un sistema que pueda verificar de manera confiable que el software se comporta como se espera, incluso cuando se enfrenta a los datos más impredecibles y complejos imaginables.