hypothesis-cats

[Paul Wolneykien]

Hi!

I've just written this package to use it for testing validation functions and some other my stuff:

https://github.com/wolneykien/hypothesis-cats

What do you think about the approach? TIA

[Zac Hatfield Dodds]

In my experience it's a tempting pattern due to the convenience.  This does make me nervous though, for the following reasons:

• You're replacing individual tests with a DSL - and just as you can have 'missed tests', you can have missed cases or confusing semantics in the DSL.
• The example doesn't - to my sensibilities - save enough code to have a net-lower cognitive burden than writing the Python test code directly.
• It's much harder to be confident that each subset of the edge cases are being handled correctly when they don't have a separate test each.  You can mitigate this by using event() and checking --hypothesis-show-statistics or using HypoFuzz, or I guess by clever use of target(), but it's still a new problem to deal with.
• The framework itself can have bugs.  In general I prefer test code to be as simple and obvious as possible - less code is better, even if that means more of it is right there.

To be clear I don't think it's a bad library, just not a style of tool that I'd use, and I'm always happy to see people build stuff on top of Hypothesis!

Zac

--
You received this message because you are subscribed to the Google Groups "Hypothesis users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypothesis-use...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hypothesis-users/4fcd4f7f-efdc-4880-beaa-576f450985dcn%40googlegroups.com.

[Paul Wolneykien]

В Thu, 28 Jul 2022 23:43:31 -0700
Zac Hatfield Dodds <zac.hatfi...@gmail.com> пишет:

> The example doesn't - to my sensibilities - save enough code to have a net-lower cognitive burden than writing the Python test code directly.

Hi! I've figured out more logical and compact syntax:

@given_divided(
name={
'empty': {
'raises': {
'err': TypeError,
'pattern': '^Name'
},
'values': text(max_size=0)
},
'non-empty': text(min_size=1)
},
role=text(),
...
}

As compared to the previous one, there is no need to duplicate
parameter names and for simple categories it is possible to
directly specify the desired strategy. Simple (i.e. non-subdivided)
values are also possible.