Closed nicoabie closed 1 month ago
The value is that you don't need to write all the possible scenarios that will produce the same output from the lexer.
what are all the posible statements that produce vec![TokenProperty::from(SyntaxKind::Select)]
?
select ; select select 1; select 1 select 'a'; select 'a' select 1 as alias; select 1 as alias select 'a' as alias; select 'a' as alias
and now combinations of the previous selecting more than one field.
maybe more? I didn't get into the details of how it works
And now:
'contact' or 'apple' represent all the possible table names? not really therefore you can have a custom arbitrary that generates valid names that respect postgres constraints.
how many unit tests would you need to really make sure test_select_with_where
works?
let's see all the possible combinations.
test_simple_select
That is the value of proptesting, there is no way one can write all the combinations by hand. I guess it depends on the confidence you want/need.
Question is, how do you make the LLM to have that coverage of the domain of the problem?
What kind of change does this PR introduce?
POC of using proptest to help finish the parser #51 What I want to show with this little PR is how easy is to generate families of tests.
What is the current behavior?
Static unit tests
What is the new behavior?
Generated unit tests
Additional context
There are two crates quickcheck and proptest, I found the documentation of proptest easier to understand for newcomers. I 've used PBT in different languages (prolog, scheme, javascript and python) but never in rust so this is my first time.
https://altsysrq.github.io/proptest-book/intro.html