-
-
Notifications
You must be signed in to change notification settings - Fork 176
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
π₯ Error with cause by default #4489
Conversation
We offer a fallback for users willing to preserve the old behaviour. Indeed, for now, not all test runners properly support causes attached to the Error. As a consequence, not offering a way to rely on the legacy format would block some users to V3.
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 97fbcff:
|
Codecov ReportAll modified and coverable lines are covered by tests β
Additional details and impacted files@@ Coverage Diff @@
## next-3_14_0 #4489 +/- ##
===============================================
+ Coverage 93.29% 93.39% +0.09%
===============================================
Files 207 207
Lines 5013 5013
Branches 1355 1354 -1
===============================================
+ Hits 4677 4682 +5
+ Misses 336 331 -5
Flags with carried forward coverage won't be shown. Click here to find out more. β View full report in Codecov by Sentry. |
**π₯ Breaking change** Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism. This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`. Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`. Related to #4416.
**π₯ Breaking change** Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism. This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`. Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`. Related to #4416.
**π₯ Breaking change** Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism. This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`. Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`. Related to #4416.
**π₯ Breaking change** Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism. This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`. Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`. Related to #4416.
**π₯ Breaking change** Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism. This PR makes cause mode the default. Before this PR, toggling it was possible via `errorWithCause: true` on `fc.assert`. Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via `includeErrorInReport: true` on `fc.assert`. Related to #4416.
π₯ Breaking change
Until now, fast-check have been merging the content and stack of the original Error that caused the property to fail into its own Error. With the recent (2022) introduction of cause on Errors, this complex logic can be dropped in favor of the native cause mechanism.
This PR makes cause mode the default. Before this PR, toggling it was possible via
errorWithCause: true
onfc.assert
.Given not all test runners properly support causes attached to the Error, we offer a fallback for users willing to preserve the old behaviour. It can be toggled via
includeErrorInReport: true
onfc.assert
.Related to #4416.
Category:
Potential impacts: