El triste estado de las bibliotecas de pruebas basadas en propiedades

• Las pruebas basadas en propiedades son un raro ejemplo de investigación académica que logró volverse parte de la corriente principal en menos de 30 años.
• Bajo el eslogan "no escribas pruebas, genéralas", han recibido apoyo en comunidades de muchos lenguajes de programación.
• La página de Wikipedia de QuickCheck, originalmente una biblioteca de Haskell, enumera 57 reimplementaciones en otros lenguajes.

Investigación sobre bibliotecas de pruebas basadas en propiedades

• Se investigaron las bibliotecas de pruebas basadas en propiedades más usadas actualmente y se compararon con el estado del arte de hace 15 años (2009).
• La mayoría de las bibliotecas no ofrecen las funciones más avanzadas de pruebas basadas en propiedades.

¿Por qué las bibliotecas de pruebas basadas en propiedades están en un estado tan triste?

Las pruebas basadas en estado y en paralelo no son tan útiles como las pruebas puras

• El modelado basado en estado requiere capacitación.
• Se plantea que el código cerrado ayuda a la adopción industrial.

El modelado basado en estado requiere capacitación

• Las pruebas basadas en estado y en paralelo exigen una forma de pensar distinta a la de las pruebas comunes.
• Al ofrecer estas herramientas a usuarios nuevos, se necesita una capacitación adecuada.

Se plantea que el código cerrado ayuda a la adopción industrial

• Se argumenta que el código abierto no funcionó y que los productos de código cerrado junto con servicios relacionados ayudan a la adopción.

Lo que podemos hacer

• Proporcionar implementaciones cortas de código abierto para pruebas basadas en propiedades con estado y en paralelo.
• Hacer más sencilla la parte de especificación formal para que requiera menos capacitación de los desarrolladores.

Resumen de las pruebas basadas en propiedades puras

• Probar una nueva función o característica se considera una buena práctica.
• Por ejemplo, si escribiste una función reverse para invertir una lista enlazada, tiene sentido probarla con algunas listas, como la lista vacía.
• Generar entradas aleatorias es la función principal de las pruebas basadas en propiedades.
• La idea es que las entradas aleatorias eventualmente encontrarán casos extremos.

Pruebas de propiedades basadas en estado

• Al probar componentes con estado, la misma entrada no produce la misma salida.
• En las pruebas basadas en estado, se generan secuencias de entradas para probar cómo cambia el sistema con el tiempo.
• El estado se describe explícitamente usando una implementación de referencia en memoria (modelo).

Ejemplo: contador

• Se implementa un contador usando una variable global mutable.
• El modelo se representa como un entero.
• La prueba genera y ejecuta una secuencia de comandos para comparar la salida real con la salida del modelo.

Pruebas basadas en propiedades en paralelo

• Las pruebas en paralelo reutilizan el modelo de pruebas basadas en estado para detectar condiciones de carrera.
• Las pruebas en paralelo usan un modelo secuencial de máquina de estados para realizar pruebas paralelas mediante linearizabilidad.

Conclusión y trabajo futuro

• Para mejorar el estado de las pruebas basadas en propiedades, es necesario ofrecer implementaciones de código abierto y facilitar las especificaciones formales.

Opinión de GN⁺

• Este artículo explica bien la historia y el estado actual de las pruebas basadas en propiedades.
• Destaca la importancia de las pruebas basadas en estado y en paralelo, y plantea la necesidad de implementaciones de código abierto.
• Propone formas de hacer que las pruebas basadas en propiedades sean más accesibles.
• Otros proyectos con funciones similares incluyen Hypothesis (Python) y PropEr (Erlang).
• Enfatiza que al adoptar nuevas tecnologías o proyectos de código abierto se necesita capacitación y soporte.

[GN⁺]

Comentarios en Hacker News

• La experiencia usando clojure.spec.alpha y test.check fue buena
  • Se dejó de usar hypothesis de Python porque no podía manejar conjuntos de datos grandes
• El fuzzing basado en cobertura está bien soportado en Go
  • Con pruebas de fuzzing y verificaciones de invariantes se pueden obtener resultados similares a las pruebas basadas en propiedades
• La exigencia de que los artículos de investigación deban poder reproducirse con herramientas de código abierto puede hacer que se pierda información útil
• En Rust se escriben con frecuencia pruebas basadas en propiedades con estado usando proptest
  • Las pruebas en paralelo a veces son útiles, pero puede ser más fácil ejecutar varias pruebas en paralelo
• Se leyó el artículo de Quviq QuickCheck, pero escribir directamente pruebas basadas en estado podría ser mejor
  • StateModel requiere código adicional de framework, por lo que no es eficiente
• Además de las máquinas de estado y el aspecto paralelo, las pruebas basadas en propiedades con cobertura podrían tener un mayor impacto
  • Es importante mantener todas las invariantes al generar valores mientras se conserva la reducción automática
  • El enfoque de "reducción interna" de Hypothesis es el más efectivo
• Clojure también tiene una biblioteca QuickCheck basada en estado
  • Las pruebas en paralelo todavía no son un gran problema
• Si se pueden escribir pruebas estrictas, es mejor integrar las pruebas basadas en propiedades en el sistema de tipos
  • Para simples "smoke tests", es más fácil usar entradas aleatorias
• También existe QuickCheck Mini, la versión gratuita de QuviQ Erlang QuickCheck
• En JavaScript, hay curiosidad por saber si una biblioteca de pruebas basadas en propiedades puede generar valores aleatorios que no satisfagan ciertas condiciones