Skip to content

Conversation

@Liam-DeVoe
Copy link
Member

@Liam-DeVoe Liam-DeVoe commented Jan 2, 2026

I'm interested to hear what people think about this one.

A concern I have is max_examples becomes more confusing to users when everything else refers to "test cases". I think this is fine, because max_examples is one of the first keywords a user learns in hypothesis (just after "strategies"), and likely before they encounter "test cases". So the confusion is when they first encounter "test cases", not max_examples. And we already use test cases in some places, so I mostly view this as pushing the confusion earlier, not new disharmony. (to be clear I don't necessarily think this is good, just not as bad as it could be.)

I've also made these two not-strictly-related wording changes (falsifying -> failing, drop "trying"), in trying to give some love to our debug logging:

  • Falsifying example: test_integers( -> Failing test case: test_integers(
  • Trying example: f( -> Test case: f(

@Liam-DeVoe Liam-DeVoe requested a review from Zac-HD as a code owner January 2, 2026 06:47
@Zac-HD
Copy link
Member

Zac-HD commented Jan 3, 2026

Hmm. I feel pretty good about generally tidying up our language and settling on specific names for things, but I think I'd want to have a more complete view before shipping it.

Maybe we should write up explicit "user glossary" and "contributor glossary" docs to identify what terms need definitions or explanation? Explaining existing use of terms is already a nice improvement on the status quo; and then after that we can decide whether it's worth changing some of them. (e.g.: I find all of 'example', 'input', and 'test case' natural in slightly different situations 🙈)

@Liam-DeVoe
Copy link
Member Author

My thoughts:

  • "example" only for @example or .example()
  • "input" for very casual or introductory commentary
    • eg our tutorial might introduce test cases as inputs, then make that more rigorous later on.
  • "test case" everywhere else

It's tempting to harmonize max_examples documentation by using "example" there, but I prefer the consistency of "test case" and adding a ..note :: stating the relation.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants