mmichaelis
commented
8 years ago :blush: Had some trouble because IntelliJ Idea formats in another way than the Eclipse settings. Would be easier to adapt Idea settings than to use the plugin which does not always apply the format.
And at the end it was Idea's "Optimize Imports" which I had enabled for commit which broke the previous change of spotlessApply.
Overview
I am actually done with a first proposal especially regarding issue #21. Instead of just having actual and expected values only you can now provide a complete set of values which might be useful for debugging purpose.
What I had in mind where especially system tests (and more specifically Web UI tests as they are one of the test types I am most involved in). That's why one of the examples for possible debug information to provide are images.
Issues
This PR changes the complete structure of the exception and addresses also the following issues:
22 Robustness:
ValueWrapper(nowValueDescriptor) is also robust against failures intoString()methods.21 DebugInformation: the main issue about providing more than just actual/expected
20 Common Exception Creation: As all but the multi failure exception have the very same constructors they are easy to be created by strategies.
9 (partially/enablement) Common Test Reports: Having a look at the Allure Framework it might be easier to provide for example Attachments now within the
DebugInformation.4 Detach from AssertionError: The new hierarchy is now basically based on
RuntimeExceptionand a new top level exception which isDebuggableException.Discussion
The workspace contains a
README.mdwith some discussion elements I will state here again:Difference ValueDescriptor vs. ValueWrapper
While developing the
ValueWrapperit seems at some points that theValueWrappercould actually replace theValueDescriptor. It just needs to store identity hashcode and value oftoStringin the data map.But: The roles are slightly different. A
ValueWrapperis especially responsible for providing a serializable representation of the object so that theValueDescriptorcan try its best to store the value in a convenient manner to be part of the exception description (thus it needs to be serializable).The
ValueWrapperis especially meant to be used internally within theValueDescriptor. That is why theValueDescriptorprovides no direct access to theValueWrapper.ValueWrapper: Object or Generics?
Should the ValueWrapper return the stored value as object or as generic type? Using
Objectas return type provides more flexibility to theValueWrapper. It might for example decide that the deserialized object is of another type than the serialized one. Using a generic type would prevent this feature.Provide RenderedImageSerializer?
Should the core of OpenTest4J provide a serializer for rendered images? In terms of providing the very core for test assertions it should not be part of it. Nevertheless it is a typical for example for UI tests what you would provide a screenshot in addition to other debug information.
So we might place it into the tests section to serve as example and as test for the extensibility. Or we might provide a separate module/project with examples for serializers.
Using Java Service Provider Framework?
The advantage of this framework is, that it is at hand without any additional dependencies. And: It provides a good extension point for additional serializers.
But it also raises some questions:
DefaultValueSerializerbe part of the service configuration and as such overridable?DebugInformationDefaultKey
I think it is useful to provide some common defaults we agree upon. But what are these defaults? expected, actual and perhaps a mismatchDescription? And is it better to provide it as enum or just plain String constants?
Conclusion
I think the given result will help me in my work with Web UI tests where I need to collect information like:
Nonetheless I am happy if I could just bring up some ideas.
I hereby agree to the terms of the Open Test Alliance Contributor License Agreement.