Capture non Serializable inputs to ValueWrapper as transient field #54
Conversation
justintuchek
changed the title
| @@ -122,6 +124,14 @@ public int getIdentityHashCode() { | |||
| return this.identityHashCode; | |||
| } | |||
|
|
|||
| /** | |||
| * Returns the value supplied to {@link #create(Object)}. if {@code ValueWrapper} | |||
| * has been been serialized this will return {@code null} | |||
There was a problem hiding this comment.
Please add a blank line after the first sentence and start the new paragraph with <p>.
There was a problem hiding this comment.
Can do, thanks for the feedback!
There was a problem hiding this comment.
Set to 1.2 as that's the current snapshot version listed in master since last release 👍
|
Hey @marcphilipp would you be able to give this a second look? |
| @@ -158,6 +158,23 @@ public void deserializationOfAssertionFailedErrorWorksForVersion_1_0_0() throws | |||
| assertEquals("bar", error.getActual().getValue()); | |||
| } | |||
|
|
|||
| @Test | |||
| public void ephemeralValueIsOmittedFromSerialization() throws Exception { | |||
There was a problem hiding this comment.
Hm, wouldn't this make more sense if value itself was Serializable, maybe add another variant with that?
There was a problem hiding this comment.
The original intent was to verify the behavior of ephemeralValue through serialization, which should return null when given a non-serializable value.
I'm not opposed to adding more test but there are already a handful that exercise AssertionFailedError and ValueWrapper with serializable values.
|
Thanks, @justintuchek! 👍 |
Overview
There seems to have been some discussion about this in the past: #2 #49 and #50
This constraint can be hard to work with if somebody is trying to use those values but has no control over what a user inputs into their assertions.
A concrete example:
JUnit 5 has an extension model which allows for processing of test cases and failure scenarios, such as TestExcecutionExceptionHandler.
During the execution of those extensions we are still in the same runtime. Having access to provided test inputs would be helpful for processing real objects - as compared to analyzing only their string representation
A proposed solution:
Exposing the same instance as a transient field will keep compatibility for Serialized requirements but allow access in test frameworks.
Given the ephemeral object is the same instance it would have a very minimal impact on
ValueWrapperasidentityHashCode(),toString(), andgetType()would remain unchanged.I hereby agree to the terms of the Open Test Alliance Contributor License Agreement.