Comment by locknitpicker

> (...) but in the end of the day, you somehow need to derive the expected outputs from input arguments, just like your SUT does.

I think you're manifesting some misconceptions and ignorance about property-based testing.

Property-based testing is still automated testing. You still have a sut and you still exercise it to verify and validate invariants. This does not change.

The core trait of property-based testing is that instead of having to define and maintain hard coded test data to drive your tests, which are specific realizations of the input state, property-based testing instead focuses on generating sequences of randomly-generated input data, and in the event of a test failing it follows up with employing reduction strategies to distil input values that pinpoint minimum reproducible examples.

As a consequence, tests don't focus on which specific value a sut returns when given a specific input value. Instead, they focus on verifying more general properties of a sut.

Perhaps the main advantage of property-based testing is that developers don't need to maintain test data anymore, and this tests are no longer be green just because you forgot to update the test data to cover a scenario or to reflect an edge case. Developers instead define test data generators, and the property-based testing framework implements the hard parts such as the input distillation step.

Property-based testing is no silver bullet though.

> Despite some anecdata in the comments here, the chances are slim that this approach will find edge cases that you couldn't think of.

Your comment completely misses the point of property-based testing. You still need to exercise your sut to cover scenarios. Where property-based testing excels is that you no longer have to maintain curated sets of test data, or update them whenever you update a component. Your inputs are already randomly generated following the strategy you specified.