You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an exception or error occurs in a PHPUnit extension it does not prevent the test from continuing execution. This is by-design, and there's no mechanism to accomplish this with what PHPUnit provides to extensions. The PHPUnit maintainers, do not appear open to changing this.
On top of the tests continuing, the error messages displayed by the test runner are not always informative enough to reliably debug what's happened. Stack traces, for example, often include only PHPUnit's internal methods and more thorough debugging is required to figure out what's happened. Since we won't have a first-class mechanism in PHPUnit to accomplish this we need to come up with a thorough, easy-to-use way to provide more useful information.
Alternatively, we could decide to skip the extension approach completely and implement PHPUnit's integration as a trait instead. This has its own drawbacks and pitfalls. Unfortunately, there is no "good" answer here and whatever we come up with to workaround this issue will complicate the codebase or present a less-than-ideal integration point.
A third option would be to hard exit() on failure with a descriptive message of what's went wrong. This feels like a really heavy-handed approach but might be an option.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
If an exception or error occurs in a PHPUnit extension it does not prevent the test from continuing execution. This is by-design, and there's no mechanism to accomplish this with what PHPUnit provides to extensions. The PHPUnit maintainers, do not appear open to changing this.
On top of the tests continuing, the error messages displayed by the test runner are not always informative enough to reliably debug what's happened. Stack traces, for example, often include only PHPUnit's internal methods and more thorough debugging is required to figure out what's happened. Since we won't have a first-class mechanism in PHPUnit to accomplish this we need to come up with a thorough, easy-to-use way to provide more useful information.
Alternatively, we could decide to skip the extension approach completely and implement PHPUnit's integration as a trait instead. This has its own drawbacks and pitfalls. Unfortunately, there is no "good" answer here and whatever we come up with to workaround this issue will complicate the codebase or present a less-than-ideal integration point.
A third option would be to hard
exit()
on failure with a descriptive message of what's went wrong. This feels like a really heavy-handed approach but might be an option.The text was updated successfully, but these errors were encountered: