Skip to content
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.

Arbitrary generation #3

Open
jkarni opened this issue Apr 26, 2016 · 2 comments
Open

Arbitrary generation #3

jkarni opened this issue Apr 26, 2016 · 2 comments

Comments

@jkarni
Copy link
Member

jkarni commented Apr 26, 2016

Currently we use Arbitrary for everything. This runs into an issue that makes testing particular endpoints not very effective. To see why, consider a typical CRUD set of endpoints (where e.g. "user/:id" is one of the GET endpoints). With a clean DB, arbitrary generation of IDs will almost never result in a query to an existing user - even if servant-quickcheck POSTs a new arbitrary user, the likelihood of it GETting that user is very small.

I think the way to go is to have a class with an IO a (rather than Gen a) method. This would allow library users to for example specify that Id should be taken from the list of IDs in the database.

@soenkehahn
Copy link

I haven't looked into it a lot, but maybe this contains some relevant ideas:
http://quviq.com/documentation/eqc/eqc_statem.html

(From http://quviq.com/documentation/eqc/index.html)

@jkarni
Copy link
Member Author

jkarni commented May 1, 2016

Yeah, this would be nice. I worry adding this capability on top of (Haskell) QuickCheck would be a lot more work that just having IO a, though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants