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.

Sign up for GitHub

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

Jump to bottom

Improvements on Eventually given Until deprecation #2044

Closed
3 tasks done
jschneidereit opened this issue Feb 4, 2021 · 4 comments
Closed
3 tasks done

Improvements on Eventually given Until deprecation #2044

jschneidereit opened this issue Feb 4, 2021 · 4 comments
Labels
enhancement ✨ Suggestions for adding new features or improving existing ones.
Milestone
4.4.1

Comments

@jschneidereit
Copy link
Member

jschneidereit commented Feb 4, 2021 •
edited by sksamuel

@xerus2000 pointed out some issues with my changes made in #2022 and those should be fixed:

  • EventuallyPredicate should be a typealias instead of a fun interface
  • Differentiate between a failure of the predicate and an exception in eventually
  • Add an overload that has no f for eventually so you can use eventually like you could use until (and fix the deprecation replace message)
@jschneidereit jschneidereit added the enhancement ✨ Suggestions for adding new features or improving existing ones. label Feb 4, 2021
jschneidereit added a commit that referenced this issue Feb 5, 2021
@jschneidereit
fix EventuallyPredicate, add a producerless version, and inform user …
8d40345 
…about predicate failures for #2044
@jschneidereit jschneidereit mentioned this issue Feb 5, 2021
Merged
@xeruf
Copy link
Contributor

xeruf commented Feb 5, 2021

I think we shouldn't have normal predicates, just matchers and a good way for handling them, because then we can leverage their elaborate error message generation.

@xeruf
Copy link
Contributor

xeruf commented Feb 5, 2021

By changing to soft assertion mode within the eventually block I think we can catch these more gracefully.

@jschneidereit
Copy link
Member Author

I'll look at switching to soft, but I think that probably should be up to the tester to opt in to. What if they don't want every assertion to run if one fails?

I also think the predicate is fine, consider a producer that returns a kotlin Result type and I want to gate on .isSuccess

sksamuel pushed a commit that referenced this issue Feb 9, 2021
@jschneidereit
fix EventuallyPredicate, add a producerless version, and inform user … (
3d5a15a 
#2046)

* fix EventuallyPredicate, add a producerless version, and inform user about predicate failures for #2044

* remove eventuallypredicate

* remove eventuallyPredicate from tests
@sksamuel sksamuel closed this as completed Feb 9, 2021
@sksamuel sksamuel added this to the 4.4.1 milestone Feb 9, 2021
@xeruf
Copy link
Contributor

xeruf commented Feb 9, 2021

I also think the predicate is fine, consider a producer that returns a kotlin Result type and I want to gate on .isSuccess

Totally easy with matchers: result.isSuccess shouldBe true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement ✨ Suggestions for adding new features or improving existing ones.
Projects
None yet
Milestone
4.4.1
Development

No branches or pull requests
3 participants
@sksamuel @jschneidereit @xeruf