Also a new article on why property based testing is awesome (popped up on my phone this morning): https://medium.com/@PolySync/how-i-learned-to-love-property-based-testing-62dce4fe6e8e
OvermindDL1
tmbb
Currently check all is not mixed, the generators and filters are pre-defined then there is a body block. In some cases it can make sense to mix them like if you only need one generator sometimes unless certain conditions are met that warrant the next, that way it saves processing of always acquiring the second even when not always used.
I thought you were referring to the “block version” outlined above (the one that starts with given). But in Macro-land blocks and lists are basically interchangeable, so you can pick the ine you like.
1
dimitarvp
I agree with that worry. Plus language developers aren’t gods, they are motivated volunteers and they have personal lives – increasing the maintenance cost all the time would only burn them out.
@josevalim Maybe when property-based testing makes its way to Elixir, a generic contract module (behaviour / protocol) should also be included? To allow people to plug their own (or 3rd party) implementations of property-based testing? Or maybe allow that via Mix configuration? Not sure, just throwing an idea that might help people who aren’t satisfied with the speed of the future Elixir-bultin property-based testing solution – or people who have very specific needs.
2
ericmj
Elixir Core Team
You can already run your own implementations of property-based testing. That’s what all existing libraries do today.
2
tmbb
I don’t think you need any fancy contracts for property testing. Just write a couple of macros and you’re done.
If you don’t like macros youvcan even go with functions and keep basically the dame API
2
josevalim
Creator of Elixir
In my experience having something in the standard library does not necessarily discourage others from trying different approaches. Case in point: just see @OvermindDL1’s post right below yours about him replacing Elixir’s comprehensions (and a thousand other things). 
It may even be the opposite: more people are attracted to it, which leads to more experimentation.
Right but even if we used tuples (or if map access was allowed in guards), “overriding” is_number and the usual mathematical operators to work with decimals may negatively impact overall performance. So is_number was just an example, I believe the problem as a whole goes a bit deeper. I will be quite happy to discuss this but then please start another thread so we don’t go further off-topic on this one. 
4
tmbb
I hadn’t thought of it, and you’re probably right. I mean, I’ll experiment for sure with property based testing even when stream_data is part of the standard library
1
Nezteb
You mention QuickCheck. Are Elixir’s new property-based testing capabilities intended to be an alternative to QuickCheck? I know we could still use QuickCheck regardless, but is there a reason for adding these features when QuickCheck exists?
To clarify, I love the idea of these features being added!
1
josevalim
Creator of Elixir
Stream data supports only stateless generators and QuickCheck goes way beyond.
We wanted something that is included as part of the language. See the “Why have our own implementation of property testing instead of using an existing implementation?” section in the main post.
3