-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Allow specific exceptions to be marked as failures instead of errors #4983
Comments
You do not lose the stack trace information if you chain the exceptions. |
When process isolation is used, the previous exception is lost due to #1351 - the I see |
@sebastianbergmann thanks for thinking about the technical solution. So while we can technically fix this in Drupal I think there is a question about whether this is the correct fix. Integrating PHPUnit with something like Mink that provides its own assertions is really useful. Having to use reflection to handle setting properties on exceptions feels like a not great solution. As an alternative is it possible to explore the question asked in the original comment:
|
Won't implement. |
In the Drupal project we are using Mink to drive emulated web browsers and perform assertions against web content. Mink throws its own exception when an assertion fails, and by default PHPUnit catches this and reports it as an error:
However, we would like these to be treated as assertion failures instead of errors. When presented with multiple test failures, it is usually easier to tackle the real errors first, and so being able to identify assertion failures separately is a useful feature.
Is it possible to add a feature to PHPUnit where specific classes of exceptions can be reported as failures? I have already tried catching the exception and throwing a new
AssertionFailedError
fromonNotSuccessfulTest()
but this loses the stack trace, which is critical to debugging a test fail, so it would be helpful if this feature could be configured in PHPUnit directly.The Drupal issue where this is being discussed is https://www.drupal.org/project/drupal/issues/3271214
The text was updated successfully, but these errors were encountered: