Skip to content

Conversation

Kantis
Copy link
Member

@Kantis Kantis commented May 31, 2024

We can defer the cost of creating failure messages and throwing exceptions until as late as possible. When negating/inverting matchers, we actually want the failure and in those cases the cost of generating messages+exceptions is spent in vain.

Also deferring cleaning of stacktraces to top-level saves a lot when dealing with negated matchers.

Fixes #4041


  • EqResult and EqualityResult should probably be merged into a single class before merging, since this needs to go in a major release either way
  • IterableEq is probably going away / changing in 6.0? Check what needs to be done there...

Kantis added 3 commits June 1, 2024 01:13
We can defer the cost of creating failure messages and throwing exceptions until
as late as possible. When negating/inverting matchers, we actually want the failure
and in those cases the cost of generating messages+exceptions is spent in vain.

Fixes #4041
@Kantis Kantis added the assertions 🔍 Related to the assertion mechanisms within the testing framework. label Jun 5, 2024
@AlexCue987
Copy link
Member

IMO same thing should be done in several other places, such as collection matchers: if the expected outcome is failure, they shouldn't waste time describing differences

github-merge-queue bot pushed a commit that referenced this pull request Jul 20, 2024
When we throw an AssertionError and the matcher is actually used by an
inverted matcher (i.e. we expect a failure), then the stacktrace is
irrelevant.

Partially fixes #4041 
#4048 fixes rest, but this fix can go into next patch and fixes 2/3rds
of the performance costs

<!-- 
If this PR updates documentation, please update all relevant versions of
the docs, see:
https://github.com/kotest/kotest/tree/master/documentation/versioned_docs
The documentation at
https://github.com/kotest/kotest/tree/master/documentation/docs is the
documentation for the next minor or major version _TO BE RELEASED_
-->

Co-authored-by: Sam <sam@sksamuel.com>
@sksamuel
Copy link
Member

What do we want to do with this ?

@AlexCue987
Copy link
Member

this problem persists in multiple places. this PR exposes just the tip of this iceberg. we can start making similar changes elsewhere

@Kantis
Copy link
Member Author

Kantis commented Jan 15, 2025

Agreed. I will close this PR. I tried rebasing it onto latest master but it's just too many conflicts with things I don't know anything about.

@Kantis Kantis closed this Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Significant Performance bug with "shouldNotBe" in Property Tests
3 participants