Comment by dragonwriter

Your comment is downvoted currently, but I think it has value in the discussion (despite being wrong in literally every respect) because it shows the immense misleading power of a single extraordinarily poorly chosen headline example on the project page. Testing a sorting function against the results of the sorted builtin is concise, and technically correct, but (even though there are situations where it would be exactly the right thing to do) it is completely misleading to anyone new to the concept when it comes to indicating what property-based testing is all about.

> It requires you to essentially re-implement the business logic of the SUT (subject-under-test) so that you can assert it.

It does not, and it would be next to worthless if it did. It requires being able to define the properties required of the SUT and right implement code that can refute them if they are not present (the name "hypothesis" for this library is, in fact, a reference to that; PBT treats the properties of code as a hypothesis, and attempts to refute it.)

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

No, see my reimplementation of the sorting example without resorting to the builtin (or any) sorting function other than the one being tested:

https://news.ycombinator.com/item?id=45825482

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

You may think this based on zero experience, but I have seen no one who has tried hypothesis even once who has had that experience. Its actually very good at finding edge cases.

> You as the developer know the implementation and have a chance of coming up with the edge cases.

You as the developer have a very good chance of finding the same edge cases when writing tests for your own code that you considered when writing the code. You have much less chance of finding edge case when writing tests that you missed when writing code. You can incorporate the knowledge of probable edge cases you have when crafting Hypothesis tests just as with more traditional unit tests—but with traditional unit tests you have zero chance of finding the edge cases you didn't think of. Hypothesis is, actually, quite good at that.

> Random tests are just playing the lottery, replacing thinking hard.

Property-based testing doesn’t replace the thinking that goes into traditional unit testing, it just acts as a force multiplier for it.