Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests without generators #121

Open
chris-martin opened this issue Oct 5, 2017 · 12 comments
Open

Tests without generators #121

chris-martin opened this issue Oct 5, 2017 · 12 comments

Comments

@chris-martin
Copy link
Contributor

So, Hedgehog is a property testing library, yes, but - It's also just a really great general-purpose test runner, and I've been using it for things that aren't actually property tests. The downside is that my tests run a hundred times, when they only need to run once.

Is there a quick way to modify a property so that it only checks once?

And, I don't know if this is reasonable to ask, but: Could Hedgehog be clever enough to detect whether a property ever uses a generator, and only recheck if it does?

@tmcgilchrist
Copy link
Contributor

tmcgilchrist commented Oct 5, 2017 via email

@nhibberd
Copy link
Collaborator

nhibberd commented Oct 5, 2017

The combinator is withTests 1, e.g.

@tmcgilchrist
Copy link
Contributor

tmcgilchrist commented Oct 5, 2017 via email

@kindaro
Copy link

kindaro commented Oct 5, 2017

Why not make once an alias to withTests 1 then?

@jacobstanley
Copy link
Member

I guess I figured having once was redundant, I tried not to have multiple ways of doing the same thing is all.

@jacobstanley
Copy link
Member

And, I don't know if this is reasonable to ask, but: Could Hedgehog be clever enough to detect whether a property ever uses a generator, and only recheck if it does?

I can imagine this could possibly be added in to the Test monad but I'm not sure if it's worth the complexity.

@chris-martin
Copy link
Contributor Author

chris-martin commented Oct 5, 2017

I don't mind not having a once function in hedgehog, but if it doesn't I think the withTests documentation should discuss this use case to make the solution more discoverable via search.

@jacobstanley
Copy link
Member

Yeah I completely agree

@jacobstanley
Copy link
Member

Fwiw, I would add once if enough people wanted it, but I've been trying to keep the API as thin as possible initially so that we don't grow a bunch of unnecessary functions that end up not being widely used.

@tmcgilchrist
Copy link
Contributor

tmcgilchrist commented Oct 5, 2017 via email

@fieldstrength
Copy link

Just found this issue while wondering the same.

To me, something like the once function feels quite helpful. Writing withTests 1 is easy enough, but it does look and feel wrong. It seems like the API is telling me that I'm doing something hacky or unsupported. I've never noticed the comment added to withTests that would have told me this is actually the intended way to achieve this functionality.

I'm a big proponent of property-based testing, but in practice I continue to write a lot of example-based tests, so from my perspective its quite valuable for this not to be too awkward to achieve.

(Background: I use Hedgehog a lot at work (we're quite happy with it!) where we have some utility definitions that accomplish this. Now I'm adding it to a personal project and noticing this as a friction/confusion point.)

@moodmosaic
Copy link
Member

I use Hedgehog a lot at work (we're quite happy with it!)

👍 😍

where we have some utility definitions that accomplish this

🤔 say we add once, then another request comes in for adding twice (or similar). Where do we draw the line?

In 88% of the cases we do come up with some utility functions, and I think that's where once belongs. It's like some sort of a rather special case for a property-based testing library.

In general though, just exposing a single way of doing things makes the API easier to learn for newcomers, and (often) explicit is better than implicit.

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

No branches or pull requests

8 participants