8 ms·

I got really excited about this, and I spent a little time looking through the documentation, but I can't figure out how this is different than randomizing unit

I got really excited about this, and I spent a little time looking through the documentation, but I can't figure out how this is different than randomizing unit tests? It seems if I have a unit test suite already, then that's 99% of the work? Am I misunderstanding? I am drawing my conclusions from reading the Getting Started series of the docs, especially the Workloads section: https://antithesis.com/docs/getting_started/workload.html https://antithesis.com/docs/getting_started/workload.html

jakewins 3y ago
This is that, and the exact same vibe, except: it promises to keep being that simple even after you add threads, and locks, and network calls, and disk accesses and.. With this, if you write a test for a function that makes a network call and writes the result to disk, your test will fail if your code does not handle the network call failing or stalling indefinitely, or the disk running out of space, or the power going out just before you close the file, or.. So it’s; yes, but it expands the space where testing is as easy as unit testing to cover much more interesting levels of complexity
nlavezzo 3y ago
Antithesis here - curious what part of the Getting Started doc gave you that impression? If you take a look at our How Antithesis Works page, it might help answer you question as to how Antithesis is different from just bundling your unit tests. https://antithesis.com/docs/introduction/how_antithesis_works.html https://antithesis.com/docs/introduction/how_antithesis_work... In short though, unit tests can help to inform a workload, but we don't require them. We autonomously explore software system execution paths by introducing different inputs, faults, etc., which discovers behaviors that may have been unforeseen by anyone writing unit tests.
- binarymax 3y ago
  Thanks for the response. The linked introduction does help. The workload page does give me that impression (and based on upvotes of my post it does to others as well)...so perhaps disambiguating that the void test*() examples on the workloads page are not unit tests might help! Congrats on the launch and I'll consider using it for some of my projects.

jakewins 3y ago

This is that, and the exact same vibe, except: it promises to keep being that simple even after you add threads, and locks, and network calls, and disk accesses and.. With this, if you write a test for a function that makes a network call and writes the result to disk, your test will fail if your code does not handle the network call failing or stalling indefinitely, or the disk running out of space, or the power going out just before you close the file, or.. So it’s; yes, but it expands the space where testing is as easy as unit testing to cover much more interesting levels of complexity

nlavezzo 3y ago

Antithesis here - curious what part of the Getting Started doc gave you that impression? If you take a look at our How Antithesis Works page, it might help answer you question as to how Antithesis is different from just bundling your unit tests. https://antithesis.com/docs/introduction/how_antithesis_works.html https://antithesis.com/docs/introduction/how_antithesis_work... In short though, unit tests can help to inform a workload, but we don't require them. We autonomously explore software system execution paths by introducing different inputs, faults, etc., which discovers behaviors that may have been unforeseen by anyone writing unit tests.

binarymax 3y ago
Thanks for the response. The linked introduction does help. The workload page does give me that impression (and based on upvotes of my post it does to others as well)...so perhaps disambiguating that the void test*() examples on the workloads page are not unit tests might help! Congrats on the launch and I'll consider using it for some of my projects.