You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the first instance of the test table I need to check if the value returned is not null. I actually don't care about the actual value printed by the property query writer. I help myself by adjusting the invocation to trick the system into printing a static string value ("a generated SecretKeySpec") or null. This should be better addressable because this trick needs a lot of head gymnastic to understand.
The second issue lies in the fact that we only print values and compare them. For some types which have no good toString implementation we can work with this yields also a challenge. In the example above I also used the trick to map the actual result into printing a different value. The rawValue here is also the initial value I use in a custom wrapValueFallback impl. This again works but needs a high level of understanding by the reader.
So it would be nice if we could address this and implement some more features in the query writer to support:
different match statements or a higher level concept to express
equals
contains
regex
isTrue/isFalse
isNull/isNotNull
etc
a clean way to describe how objects are compared to each other.
The text was updated successfully, but these errors were encountered:
##Description
The
PropertyQueryTaskWriter
class contains amatches
method which internally checks the result stdout for a given stringThis works fine in 90% of our usecases. I would be nice if we could extend this to pass more flexible matcher objects.
See the following usecase
In the first instance of the test table I need to check if the value returned is not
null
. I actually don't care about the actual value printed by the property query writer. I help myself by adjusting the invocation to trick the system into printing a static string value ("a generated SecretKeySpec"
) or null. This should be better addressable because this trick needs a lot of head gymnastic to understand.The second issue lies in the fact that we only print values and compare them. For some types which have no good
toString
implementation we can work with this yields also a challenge. In the example above I also used the trick to map the actual result into printing a different value. TherawValue
here is also the initial value I use in a customwrapValueFallback
impl. This again works but needs a high level of understanding by the reader.So it would be nice if we could address this and implement some more features in the query writer to support:
The text was updated successfully, but these errors were encountered: