[astahlx]

It depends on how you define testing now: Property-based testing would test sets of behaviors. The main idea is: Formalize your goal before implementing. So specification driven development would be the thing to aim for. And at some point we might be able to model check (proof) the code that has been generated. Then we are the good old idea of code synthesis.

[AstralStorm]

Don't worry, you're going to be searching for logic vs requirements mismatches instead if the thing provides proofs.

That means, you have to understand if it is even proving the properties you require for the software to work.

It's very easy to write a proof akin to a test that does not test anything useful...

[practal]

No, that misunderstands what a proof is. It is very easy to write a SPEC that does not specify anything useful. A proof does exactly what it is supposed to do.

[svieira]

No, a proof proves what it proves. It does not prove what the designer of the proof intended it to prove unless the intention and the proof align. Proving that is outside of the realm of software.

[practal]

Yes, indeed, a proof proves what it proves.

You confuse spec and proof.

[MoreQARespect]

The reason why property testing isnt used that much is because it is useful at catching tests only for a specific type of code which most people arent writing.

[9rx]

I'm not sure that's true. In essence, property tests are a method for defining types where a language lacks natural expression. In a vacuum, nearly all code could benefit from (more advanced) types. But:

1. Tradeoffs, as always. The more advanced typing you head towards, the much more time consuming it becomes to reason about the program. There is good reason for why even the most staunch type advocates rarely push for anything more advanced than monads. A handful of assertive tests is usually good enough, while requiring significantly less effort.

2. Not just time consuming, but often beyond comprehension. Most developers just don't know how to think in terms of formal proofs. Throw a language with an advanced type system, like Coq or Idris, in from of them and they wouldn't have a clue what to do with it (even ignoring the unfamiliar syntax). And with property tests, now you're asking them to not only think in advanced types, but to also effectively define the types themselves from scratch. Despite #1, I fully expect we would still see more property testing if it weren't for this huge impediment.

[MoreQARespect]

>Most developers just don't know how to think in terms of formal proofs

Formal proofs are useful on the same class of bug property tests are.

And vice versa.

The issue isnt necessarily that devs cant use them, it's that the problems they have which cause most bugs do not map on to the space of "what formal proofs are good at".

[9rx]

What do you consider to be the source of most bugs?