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.

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

Assertion error details lost in rethrow in assertWithDiagnostics #26303

Closed
lukas-krecan opened this issue Dec 20, 2020 · 3 comments
Closed

Assertion error details lost in rethrow in assertWithDiagnostics #26303

lukas-krecan opened this issue Dec 20, 2020 · 3 comments
Assignees
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@lukas-krecan
Copy link
Contributor

lukas-krecan commented Dec 20, 2020

The issue is caused by org.springframework.test.web.reactive.server.ExchangeResult.assertWithDiagnostics which catches AssertionError, adds diagnostic information and throws a new AssertionError.

The trouble is, that if you use an assertion library in WebTestClient.consumeWith the assertion library throws an exception with details like org.opentest4j.AssertionFailedError. The details are used by IDEs when displaying difference between expected and actual value. By rethrowing generic AssertionError, the extra details are lost and the IDE has to use heuristics to guess the difference (for example like this this).

To make it worse, if the IDE guesses wrong, it adds the debugging information from assertWithDiagnostics to the expected value in the difference view which is really confusing.

The best way would be to rethrow the AssertionFailedError with related detail but I understand that it would add complexity and may require reflection to not break the method when opentest4j is not on the classpath

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Dec 20, 2020
@rstoyanchev rstoyanchev self-assigned this Jan 6, 2021
@rstoyanchev rstoyanchev added in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 6, 2021
@rstoyanchev rstoyanchev added this to the 5.3.3 milestone Jan 6, 2021
@rstoyanchev
Copy link
Contributor

Re-recreating the underlying exception would be a challenge indeed. Instead I can experiment with simply logging the diagnostics, e.g. at ERROR, and then re-throwing the original exception as is.

@lukas-krecan
Copy link
Contributor Author

That makes sense.

@lukas-krecan
Copy link
Contributor Author

Alternatively, it should be possible to create a method similar to consumeWith which would pass the diagnostics information to the "consumer".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: test Issues in the test module in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants