The inputs shouldn’t be “random”, but the idea is that you should provide an input distribution that’s roughly representative of your expected distribution of r

The inputs shouldn’t be “random”, but the idea is that you should provide an input distribution that’s roughly representative of your expected distribution of real-world values (+ some perturbation to find edge cases). As for frameworks in the languages you listed... Ruby and Python: https://github.com/HypothesisWorks/hypothesis https://github.com/HypothesisWorks/hypothesis Elixir and Erlang: https://github.com/proper-testing/proper https://github.com/proper-testing/proper Node and JS: https://jsverify.github.io/ https://jsverify.github.io/ As for real world use-cases, imagine you’re writing a program that accepts timestamps as input and has to implement branching, requirements-defined business logic based off of them. When you’re writing your unit tests you can use the requirements to select timestamps that are “known good” and “known bad”, but it’s hard to explore this state space on your own. Same thing goes for handling unexpected inputs to certain functions. You probably don’t want to check _every_ type of input for _every_ dynamic function, but it might make sense to make sure that certain “entry points” to your program fail in the expected manner when they get poorly typed input.