- Antithesis busca aplicar al software en general las pruebas autónomas deterministas que dieron resultado en FoundationDB, para convertir bugs de sistemas distribuidos difíciles de reproducir en problemas repetibles
- FoundationDB creó una simulación de un solo hilo y un solo proceso antes de implementar la base de datos, y podía volver a ejecutar fallas poco frecuentes con la misma semilla aleatoria
- Este enfoque convirtió fallas no deterministas como concurrencia, latencia y reordenamiento de red, problemas de disco y caídas de máquinas en objetivos de prueba, y en FoundationDB se considera que solo hubo 1 o 2 bugs reportados por clientes durante todo el período
- Para no obligar a reescribir el software existente desde cero, Antithesis creó un hipervisor que emula una computadora determinista, y actualmente se enfoca en pruebas de confiabilidad y tolerancia a fallas para sistemas distribuidos
- Ha trabajado con MongoDB, Ethereum Foundation y Palantir, y evolucionó de ser una herramienta para encontrar bugs raros a un servicio continuo de pruebas que valida constantemente los builds más recientes
Antithesis, nacido de la experiencia con FoundationDB
- Antithesis presentó una plataforma basada en la experiencia de pruebas deterministas obtenida en FoundationDB, después de más de 5 años de desarrollo en modo sigiloso
- Antes del lanzamiento trabajó en contratación, clientes iniciales e inversionistas, y la primera idea central que mostró fue cómo probar sistemas complejos de forma repetible
El problema de validación más difícil en una base de datos distribuida
- FoundationDB comenzó en 2010 a construir una base de datos distribuida escalable, tolerante a fallas y con soporte para transacciones ACID
- En ese momento Spanner aún no se había publicado, y muchas personas incluso malinterpretaban el teorema CAP como si significara que no podían coexistir consistencia fuerte y alta disponibilidad
- La mayor dificultad no era la base de datos en sí, sino cómo probar un sistema así y ganar confianza en su corrección
Los “desconocidos desconocidos” que las pruebas tradicionales no detectan
- El software debe manejar situaciones que los desarrolladores no imaginaron de antemano, pero las pruebas comunes son fuertes para verificar casos que ya se habían previsto
- Si una situación se anticipó lo suficiente como para convertirla en una prueba, es muy probable que el código también haya sido escrito para manejarla
- Por eso, las pruebas tradicionales son útiles para evitar regresiones, pero débiles para atrapar fallas inesperadas creadas por usuarios reales y entornos de operación reales
- En los sistemas de almacenamiento distribuido este problema se vuelve aún mayor
- Existe concurrencia tanto dentro de una máquina como entre máquinas
- La red puede introducir latencia y reordenamiento de paquetes
- Las causas de falla abarcan discos, caídas de máquinas, apagones, incendios en centros de datos e incluso errores humanos
- Si un bug crítico depende del orden de eventos entre varias máquinas, puede ser difícil reproducirlo incluso después de haberlo descubierto una vez
La simulación determinista de FoundationDB
- El equipo de FoundationDB creó primero una simulación de red completamente determinista y basada en eventos, antes de escribir la base de datos
- Simuló todo el clúster dentro de una aplicación de un solo hilo y un solo proceso, y ejecutó la corrida con el mismo generador de números aleatorios
- En el clúster virtual se podían inyectar fallas de red, apagar máquinas y producir repetidamente distintas situaciones anómalas
- Si una ejecución encontraba un bug en la lógica de la aplicación, se podía volver a correr la misma secuencia de eventos usando la misma semilla aleatoria
- Gracias a esto, incluso bugs muy poco frecuentes podían rastrearse agregando logs o repitiendo procedimientos de depuración
- La charla relacionada se presentó en Strangeloop 2014, y el video puede verse aquí
Cómo las pruebas cambiaron la velocidad de desarrollo
- En FoundationDB se considera que solo hubo 1 o 2 bugs reportados por clientes en toda la historia de la empresa
- Kyle Kingsbury, es decir, “aphyr”, ni siquiera probó FoundationDB con Jepsen porque reportó que no había nada que encontrar
- Cuando las pruebas empezaron a revelar bugs nuevos de inmediato, también cambió la manera de programar del equipo
- Un compilador y un sistema de tipos fuerte brindan confianza frente a ciertos tipos de bugs, pero no es lo mismo que ejecutar software real en miles de situaciones inesperadas
- Con esa confianza, el equipo de FoundationDB se atrevió a hacer cambios grandes
- Eliminó todas las dependencias, incluido Zookeeper, y escribió en poco tiempo su propia implementación de Paxos, incluida en el paper de FoundationDB
- También reescribió por completo el subsistema de procesamiento de transacciones para hacerlo más rápido y escalable
- El mayor efecto no fue solo mejorar la estabilidad de la base de datos, sino darle a un pequeño equipo de ingeniería la productividad de un equipo 50 veces más grande
El vacío que quedó tras la adquisición por Apple
- Apple adquirió FoundationDB en 2015 y lo usó como base de la “cloud infrastructure” de Apple
- Unos años después, FoundationDB fue publicado como open source
- Incluso después de que miembros del equipo de FoundationDB se dispersaran a otras grandes empresas tecnológicas, esas organizaciones no contaban con pruebas de simulación determinista al estilo FoundationDB
- Como era difícil predecir efectos no intencionales sobre el sistema, los cambios en sistemas backend avanzaban lentamente, y diagnosticar y corregir bugs en producción consumía meses del tiempo de ingenieros senior
- En 2018, junto con Dave Scherer, se fundó Antithesis con el objetivo de llevar las pruebas autónomas deterministas al estilo FoundationDB a otros equipos
Cómo volver determinista el software existente
- FoundationDB era un proyecto greenfield diseñado desde el inicio pensando en este tipo de pruebas, y además podía eliminar sus dependencias
- El software común crea hilos, consulta la hora, pide valores aleatorios al kernel y se comunica por red con otro software
- Como una metodología de desarrollo que obligue a reescribir todo el software desde cero difícilmente puede adoptarse de forma amplia, Antithesis escribió un hipervisor que emula una computadora determinista
- Como resultado, el software que se ejecuta dentro del hipervisor puede colocarse en un entorno de ejecución determinista
- Este proceso incluye trabajar con comportamientos de bajo nivel como las extended page tables de las CPU Intel
- El problema de encontrar violaciones de propiedades en el espacio de estados de programas arbitrarios es más difícil que el problema de la parada, y puede haber propiedades de prueba incomputables incluso si existiera un oráculo de parada para todos los programas
La plataforma actual y casos de clientes
- La plataforma de Antithesis busca tomar el software del usuario, encontrar bugs y hacer que los bugs descubiertos siempre puedan reproducirse
- Intenta mantener esa reproducibilidad incluso en casos complejos donde varios servicios se comunican por red
- Después de encontrar un bug, se pueden aplicar capacidades potentes de depuración
- A largo plazo fue diseñada para encontrar muchos tipos de bugs en distintos tipos de software, pero por ahora se enfoca en lo que ya conoce bien: pruebas de confiabilidad y tolerancia a fallas en sistemas distribuidos
- Durante los últimos años ha colaborado con equipos de ingeniería que operan sistemas grandes y complejos donde la confiabilidad es crítica
- Ha trabajado varios años con MongoDB para ayudar a probar el core server software y el motor de almacenamiento WiredTiger
- Con Ethereum Foundation colaboró desde alrededor de un año antes de The Merge para apoyar las pruebas de The Merge, y sigue colaborando actualmente
- También colabora con Palantir
De herramienta para bugs raros a servicio continuo de pruebas
- Los primeros clientes usaban Antithesis como una especie de herramienta de fuerzas especiales para descubrir y reproducir los bugs más difíciles y riesgosos
- A medida que la plataforma maduró y se volvió más interactiva, pasó a convertirse en un servicio permanente que prueba continuamente los builds más recientes
- El objetivo es reducir el tiempo entre el momento en que se introduce un bug y el momento en que se descubre
- Durante el desarrollo de FoundationDB, este enfoque hizo mucho más fácil diagnosticar y corregir bugs, y elevó la eficiencia y la calidad del software
- Antithesis quiere hablar con organizaciones que operan sistemas distribuidos y valoran la confiabilidad y la productividad de ingeniería
- Para quienes quieran trabajar en problemas difíciles, dirige a su oferta laboral
1 comentarios
Opiniones de Hacker News
Siento que la expresión “legendario desarrollador 10x” se deformó hasta significar alguien que trabaja 15 horas al día, 6,5 días a la semana, y termina quemado
La verdadera productividad 10x, o incluso 50x, viene de personas que implementan algo que casi nadie creía posible o entendía, y que permiten crear software funcional en mucho menos tiempo
Demasiadas veces los gerentes prestan más atención a quien hace 8 horas de trabajo en 12 horas que a quien termina lo mismo en 8
Además, los intentos de salirse de lo “normal” no suelen verse con buenos ojos, y tampoco se incluye en el cronograma tiempo para mejorar procesos, así que se desalienta construir una carretilla cuando la situación se ve como si bastara con cargar los baldes más rápido
Por eso existen los ingenieros 10x. Al cumplir 30, no tienen 10 años de experiencia programando, sino más o menos 20
También tienen mucha más experiencia laboral. Aunque a los 15 empiecen con trabajos raros ayudando de vez en cuando a algún familiar, para los 18 más o menos ya entran a una empresa profesional y trabajan mientras estudian Ciencias de la Computación
Al menos antes era así. Fue una realidad desde 2004 hasta alrededor de 2018, pero no sé si todavía es posible con el mercado de contratación actual
Para que existan los ingenieros 10x solo hacen falta algunos ejemplos. Parece que casi todos coinciden en que son raros, y como ejemplo visible públicamente de un ingeniero 10x se puede citar a esta persona. Él jamás lo diría, pero sospecho que es un ingeniero 10x: https://bellard.org/
Si no estás de acuerdo, me da curiosidad saber en qué difieres. Yo solo estoy tocando una parte, como en los ciegos y el elefante, y no pretendo ver el panorama completo
Un desarrollador tipo ejército de una sola persona, que hace todo por su cuenta, no encaja bien en equipos donde el trabajo está estandarizado, dividido en partes pequeñas y distribuido
Ese tipo de personas rinde mejor cuando trabaja en su propio proyecto sin colegas ni gerentes que interfieran, pero la mayoría de los empleos no son así
Cuando pasan a formar parte de un equipo, por más brillantes que sean no pueden hacer demasiado por su cuenta, y al final se ralentizan resolviendo problemas creados por compañeros más lentos o más débiles, o problemas de gestión. Por eso un equipo, incluso con una estrella de rock, termina moviéndose a la velocidad del mínimo común denominador
También ayuda que estamos creando herramientas internas y estamos muy cerca de los procesos y de los stakeholders
“Hmm, hay otra forma de lograr esto” es lo que cuenta como 10x; hacerlo más rápido no es lo central
Quizá sea una de las mejores introducciones que he leído hasta ahora
Sienta muy bien las bases sobre quiénes son las personas y qué han creado, y explica que lo que están construyendo ahora es consecuencia de lo que hicieron antes
Da la impresión de que quieren resolver este problema para todos porque ellos mismos ya experimentaron lo buena que es la solución
Luego también muestran equipos que ya la usaron, con nombres bastante grandes que tienen sistemas complejos
Todo eso está envuelto en un buen texto que funciona bien para desarrolladores y fundadores, y la landing page también es excelente
Me habría gustado ver algunos casos de uso y ejemplos reales
En cambio, enumeran nombres de algunas grandes empresas, afirman que es un producto innovador que funciona como por arte de magia y luego meten buzzwords típicas como “programador 10x” y “modo stealth”. Hablar de modo stealth mientras publican nombres de clientes no tiene mucho sentido
Como ofrece una forma de vivir, pensar y ejecutar que no había experimentado hasta ahora, hace que quiera esa solución
El artículo enlazado es 3/4 historia y justificación antes de decir qué fue lo que realmente construyeron
Es como esos blogs de recetas molestos en los que quieres hacer panqueques veganos, pero primero te sueltan la historia de la infancia del autor
Es un pitch excelente y no quiero sonar negativo, pero siento que una frase como “encontramos todos los bugs” solo puede ser cierta si se toma una definición de bug muy estrecha.
Los bugs más perversos y difíciles de encontrar que he enfrentado no tenían que ver tanto con caer en un estado de error, sino con la lógica de negocio de la aplicación.
Por ejemplo, ¿cómo debería mostrarse en la página de transacciones recientes de un cliente el caso en que la base de datos registra una transacción completada del cliente, pero no hay ningún artículo comprado completado?
En esos casos, implementar “algo aparece y no crashea” es muy distinto de garantizar que la decisión realmente tenga sentido en el contexto de las demás decisiones a lo largo de todo el stack.
En una base de datos también hay problemas como “el query planner genera un plan muy ineficiente para este caso límite”.
Este tipo de cosas no se puede detectar automáticamente. No se trata de que el programa llegue a un estado de error, sino de entender qué significa “correcto” en la aplicación desde el principio.
Puede que esté poniendo el estándar de bug demasiado alto, pero imaginar cero bugs no es lo mismo que crear software en el mundo real. Aun así, cero errores en runtime sí me parecería aceptable.
Dicho eso, es cierto que FoundationDB es muy famosa por haber llevado las prácticas de testing a la vanguardia: https://apple.github.io/foundationdb/testing.html
Normalmente eso sonaría arrogante o demasiado confiado, pero en este caso de verdad llegaron muy cerca de cero bugs.
Claro que no se puede probar una proposición negativa, pero el hecho de haber llegado a ese estado de “todo en verde” daba mucha confianza de que estaban construyendo sobre una base sólida, y con el tiempo se vio que efectivamente era así.
Los problemas alrededor de la lógica de negocio no son una falla del sistema: el sistema funcionó según la especificación, y como la especificación no era lo bastante abarcadora, ahora toca iterar y mejorarla.
Por supuesto, a mucho software le falta documentación, y eso es un bug de documentación.
Aun así, esta definición me gusta porque, incluso si la documentación está incompleta, te obliga a preguntar: “¿de verdad vamos a documentar este comportamiento, o vamos a cambiar el comportamiento y documentar eso?”.
Al menos a mí me hace más difícil barrer bajo la alfombra un comportamiento raro.
Me interesé muchísimo en este campo después de conocerlo por la guía de simulación de
sledhttps://sled.rs/simulation.html, que muestra a grandes rasgos cómo lo hace FoundationDB.Ahora estoy trabajando para introducir una estrategia de testing similar en mi trabajo, escribiendo nuestro servicio para que se ejecute sobre
madsimhttps://github.com/madsim-rs/madsim?tab=readme-ov-file#madsim.Esto permite seguir escribiendo servicios con el estilo async/await de tokio, pero en las pruebas cambiar todo por un ejecutor determinista que parchea todas las fuentes de no determinismo, incluidas las dependencias que llaman al sistema operativo. Funciona de forma bastante fluida.
El autor de este artículo no exagera cuando dice que el costo inicial es enorme. Manejar todas las fuentes posibles de no determinismo y reescribir los servicios para que sean testeables y tengan una forma sans-IO https://sans-io.readthedocs.io/ requiere mucho esfuerzo de ingeniería.
Pero una vez que el sistema está armado, es difícil expresar con palabras la confianza que sientes en el código. Combinado con herramientas como quickcheck https://github.com/BurntSushi/quickcheck?tab=readme-ov-file#quickcheck, puedes probar cientos de miles de casos sutiles de falla: entrada/salida, orden de eventos, timeouts, pérdida de paquetes, fallas del sistema de archivos, etc.
Este tipo de pruebas es una herramienta muy poderosa para tener en la caja de herramientas si tienes la paciencia y la perseverancia para invertir en ella.
Antithesis en sí también se ve muy interesante. Llevar el testing determinista hasta una capa por debajo del sistema operativo es impresionante, y parece que permitirá probar sistemas completos sin tener que armar manualmente un harness cada vez. Tengo muchas ganas de probarlo.
Gran parte de la complejidad que he visto en esos sistemas viene de que las llamadas a “funciones” son asíncronas, dependen del sistema operativo, pueden ejecutarse algún día o no ejecutarse nunca, devuelven paquetes de strings que hay que parsear para volver a entrar al sistema de tipos estático, y además tienen sus propios modos de falla.
Algo que en apariencia es simple, como abstraer lógica en un componente con nombre —es decir, una función—, se vuelve extremadamente complejo.
Si mantienes la lógica dentro del mismo proceso y simplemente llamas a funciones, no necesitas probar los fallos sutiles mencionados.
Un monolito no siempre es la mejor opción ni siempre es correcto, pero soy muy escéptico de que la moda actual de las arquitecturas de software basadas en servicios esté justificada y tenga una recompensa proporcional.
También me pregunto si hay empresas que usen Rust y estén desarrollando de esta manera.
Por cierto, TigerBeetle también es un producto escrito de esta forma.
madsimo pruebas de simulación determinista.El artículo es realmente entretenido
Si puedes escribir una frase como “programar en este estado es como vivir rodeado de un campo de fuerza que te protege de todo daño… Como teníamos bugs, eliminamos todas las dependencias, incluido Zookeeper, y en muy poco tiempo escribimos nuestra propia implementación de Paxos, que no tenía bugs”, y respaldarla con evidencia, debe ser algo increíble
En ese libro dicen que, por los bugs en los paquetes de software numérico, era tan frustrante terminar depurando software ajeno mientras intentaban resolver su propio problema, que normalmente hacían sus propias implementaciones, salvo por paquetes de álgebra lineal
Consideraban que lo más problemático era que los paquetes ocultaban defectos en la formulación del problema. Si metes un conjunto de ecuaciones en un solver, aunque esté mal condicionado o tenga singularidades inesperadas y la respuesta se aparte de la realidad física, por lo general entregará una solución sin quejarse; y si eso está enterrado dentro de un programa grande, puede hacer que ignores esa posibilidad
Incluso si detectas un comportamiento sospechoso, es difícil meterte dentro del paquete para investigar el problema, así que al final tienes que volver a programarlo tú mismo; y dicen que, si lo hubieras hecho así desde el principio, probablemente te habrías metido más a fondo en la realidad del problema y habrías eliminado antes la confusión lógica
Al final, hacerlo o no depende de qué tan riguroso seas, qué tan rigurosa sea una dependencia concreta y cuánto tiempo tengas. Yo no escribiría mi propia base de datos, porque es demasiado compleja y hay muchas opciones bien probadas. En cambio, si solo usas una parte de un paquete pequeño con pruebas débiles, puede tener sentido hacerlo tú mismo
Aunque no afirmo que mi especificación no tenga bugs
Me vienen tres ideas
Primero, es una gran idea que llega en el momento adecuado. Viendo el sentimiento de los desarrolladores respecto de fuzzers, tipos estáticos, seguridad de memoria, protocolos estandarizados, contenedores, etc., da la impresión de que la gente por fin está perdiendo la paciencia con el software inestable
Segundo, parece apuntar a un nicho de mercado. Cuesta 2 dólares por CPU por hora, 7000 dólares al año por CPU con reserva, no tiene un nivel gratuito para hobbies ni para software libre/open source, y para probarlo o comprarlo hay que contactarlos. Es un modelo de negocio doloroso, pero válido. Aun así, es una lástima que no busquen el máximo impacto positivo posible
Tercero, la calidad del artículo y la documentación es alta, y me encanta que la documentación incluya frases como “si se encuentra un bug en producción o lo encuentra un cliente, deberían exigirnos una explicación”
Así es como te ganas la simpatía de los desarrolladores. Me recuerda a Mullvad, que sigo recomendando a la gente aunque en el pasado me decepcionó
Lo mencionaron al respecto en https://news.ycombinator.com/item?id=39358526. Como referencia, soy cofundador de Antithesis
El hardware también podría empezar a agregar funciones para soportarlo, y dentro de 30 años quizá esta sea simplemente la forma en que funciona la computación
Pero antes de que los pioneros logren difundirlo de verdad, primero tienen que recuperar el costo de las flechas que recibieron. Hay que verlo no como un hecho aislado, sino como el inicio de un proceso
A juzgar por la documentación, los bugs que esta plataforma está diseñada para encontrar son de ese tipo difícil, “irreproducible”, que solo aparece rara vez en producción
La mayoría de los equipos tienen problemas mucho más grandes y bugs evidentes que corregir. De hecho, la mayor parte del software en producción hoy apenas tiene pruebas unitarias
Me pregunto cómo se multiplican los costos en casos de uso reales
Este año conocí a Antithesis en Strangeloop y hablé con su equipo; incluso comparándolo con el estado del arte de la inyección automática de fallas que seguía cuando trabajaba en Amazon, creo que este producto es un salto enorme frente a muchos sistemas de verificación formal que se usan hoy
De hecho, pude seguir el proceso de rastreo de bugs de un problema que encontraron en Apache Spark Streaming. Según la documentación, encontraron un error de corrección sutil y desagradable en una operación común, un caso límite de baja visibilidad que habría sido un dolor de cabeza durante años
Al final resultó que la documentación estaba equivocada, pero después de ver ese proceso me cuesta imaginar lo importante que pueden llegar a ser herramientas como Antithesis dentro de empresas que construyen sistemas distribuidos
Ojalá pronto publiquen un blog post que entre en detalles técnicos. Me gustaría escuchar cómo llegaron a su enfoque actual
No quiero subirme de inmediato al ciclo de expectativas infladas, pero esto suena como el Santo Grial. ¿No basta con usar una aplicación existente tal cual y, asumiendo que está contenerizada, verificar propiedades encima de ella?
El punto en el que siempre nos trabábamos era la base de la máquina: la CPU y el sistema operativo no deterministas
Como rehacer toda la pila vertical de computación es prácticamente imposible, ellos esquivaron el problema creando un simulador determinista de alta fidelidad
Eso sí, me pregunto cómo verifican la equivalencia entre el simulador y un sistema operativo existente. Suena a una tarea nada trivial. Aun así, la idea me convence bastante
Luego ejecutan las pruebas inyectando todo tipo de fallas: fallas del sistema operativo, problemas de red, condiciones de carrera y de timing, problemas con generadores de números aleatorios, etc.
Es muy posible que hoy sea la única forma práctica de probar estas cosas de manera confiable, pero aun así tienes que escribir todas las pruebas y definir el estado de la aplicación
Dicen que es una “plataforma que recibe software y caza bugs dentro de él”, pero entonces, en la práctica, ¿qué es?
Parece un servicio en la nube que ejecuta pruebas de integración. Da la impresión de que hay que averiguar cómo desplegar en este entorno especial, y que igual hay que escribir pruebas de integración usando librerías especiales.
Pero aun haciendo todo ese refactor de integración, no entiendo cómo encontraría bugs reales que mis propias pruebas de integración en mi entorno no habrían encontrado ya.
Dicho eso, Antithesis no exige pruebas manuales ni escribir pruebas de integración.
Hay que empaquetar el sistema de software en contenedores, lo cual es relativamente sencillo, y luego escribir una carga de trabajo que imite el funcionamiento normal del sistema. Por ejemplo, para un sitio de e-commerce sería ver productos, agregarlos al carrito, pagar, etc.
Con eso, Antithesis empieza a probar el software ejecutando la carga de trabajo, cambiando entradas e inyectando fallas, y busca violaciones de propiedades de prueba.
Vienen incluidas más de 60 propiedades de prueba, como crashes, falta de memoria, etc. Para exponer mejor problemas propios del sistema, también se pueden definir propiedades personalizadas y, de hecho, conviene hacerlo.
A medida que se ejecutan las pruebas, se reportan violaciones de propiedades con mucha información útil de depuración. Las ejecuciones de prueba especialmente interesantes se pueden rebobinar, modificar entradas, obtener artefactos, agregar logging, etc., así que permiten mucho análisis adicional.
Hasta ahora eso es todo lo que sé. Supongo que habrá alguna forma de fuzzing y análisis estático, o una definición de las acciones que el software puede realizar.
Sinceramente, parece que se superpone bastante con lo que el lenguaje Vale intenta resolver: https://vale.dev/
Pero en vez de crear un lenguaje nuevo para que el software nuevo tenga ese estado por defecto, parece enfocarse en acercar el software existente a ese estado.
Usan el hipervisor para cambiar la semilla aleatoria, hacer que las solicitudes HTTP fallen o tarden mucho, cortar conexiones entre servidores, cambiar el orden de las respuestas de los servidores y generar todo tipo de cosas que normalmente no controlas pero que ocurren en la realidad.
Luego comparan con la respuesta esperada de la carga de trabajo para determinar qué condiciones rompen el sistema.
Por eso lo venden con contratos anuales: la estructura es pagar para que la carga de trabajo se ejecute continuamente durante todo el año y pruebe todo tipo de combinaciones de fallas.
Me generó mucha expectativa y hojeé un poco la documentación, pero no termino de ver en qué se diferencia esto de las pruebas unitarias aleatorizadas.
Si ya tienes un conjunto de pruebas unitarias, me parece que eso es el 99% del trabajo. ¿Estoy entendiendo mal?
Es la conclusión a la que llegué tras leer la serie de primeros pasos de la documentación, en especial la sección Workloads https://antithesis.com/docs/getting_started/workload.html
La página How Antithesis Works puede responder en qué se diferencia de simplemente agrupar pruebas unitarias: https://antithesis.com/docs/introduction/how_antithesis_works.html
En resumen, las pruebas unitarias pueden ayudar a construir la carga de trabajo, pero no son obligatorias.
Exploramos de forma autónoma las rutas de ejecución de un sistema de software introduciendo distintas entradas, fallas, etc., y descubrimos comportamientos que quien escribió las pruebas unitarias quizá no llegó a prever.
Si escribiste una prueba para una función que hace una llamada de red y escribe el resultado en disco, la prueba fallará si tu código no maneja casos como que la llamada de red falle o quede colgada indefinidamente, que falte espacio en disco, que se corte la energía justo antes de cerrar el archivo, etc.
Así que sí, es eso, pero amplía el espacio que se puede probar con la misma facilidad que en una prueba unitaria hasta un nivel de complejidad mucho más interesante.