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

Add diff info to AssertionFailedException #39

Open
filiphr opened this issue Sep 18, 2017 · 2 comments
Open

Add diff info to AssertionFailedException #39

filiphr opened this issue Sep 18, 2017 · 2 comments

Comments

@filiphr
Copy link

filiphr commented Sep 18, 2017

AssertJ offers different ways of checking if a string is equal to something:

  • isEqualTo
  • isEqualToIgnoringWhitespace
  • isEqualToNormalizingWhitespace

IDEs (at least IntellIJ) could use this additional information to use correct options from to display the diff. If we could pass this information to the IDEs it would be of a tremendous benefit to users (especially when they use the more advanced checks)

@tonit
Copy link

tonit commented Jan 25, 2018

can you elaborate? How would you encode a generic "diff-type" as part of the payload where the left and right sides of the assertions are plain Serializables?
Let me think, so you want to encode metadata about "Operation A failed using B and C".
Right now you don't have any metadata about A in the exception payload.
So what you want is a new AssertionExpression-Type that holds Serializables B and C plus some generic way for the type of the comparism.
Sounds to me like a specialty of assertion frameworks.

What you can do probably is adding an extra pair of "Serializables" to the AssertionFailedException.
E.g. you have already:
ValueWrapper expected;
ValueWrapper actual;

But lets add:
ValueWrapper effectiveExpected;
ValueWrapper effectiveActual;

By default (most cases) it is enough to just use effectiveExpected=expected, effectiveActual=actual.
But in your cases isEqualToIgnoringWhitespace you could fill in the "normalized" versions of the values into the exception and let the IDE/Reporting show that.
I think this might be useful for assertions where some normalization should happen but usually is a side-effect rather than reported back to the user.

@FilipJirsak
Copy link

I think it can be resolved by allowing to pass custom stringRepresentation into ValueWrapper. For example my actual and expected types are JsonObject. Its toString() result (stringRepresentation) is compact JSON. It would be nice to pass pretty formatted JSON with alphabetically sorted properties as stringRepresentation together with the real expected/actual object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants