I'm running some testbox tests on CF as opposed to...
# testing
a
I'm running some testbox tests on CF as opposed to Lucee for the first time in ages. Does it surprise anyone that this works on Lucee but errors on CF?
Copy code
expect(myQuery).toHaveKey("current_date")
Where
current_date
is a column of the query. Looking into it, it's here: https://github.com/Ortus-Solutions/TestBox/blob/v4.5.0/system/Assertion.cfc#L382
Copy code
len( arguments.message ) ? arguments.message : "The key(s) [#arguments.key#] does not exist in the target object. Found keys are [#structKeyArray( arguments.target ).toString()#]"
It's barfing on
structKeyArray( arguments.target )
. The surprising thing to me is that this works on Lucee.
structKeyArray
should not accept a query 😕 The docs clearly say it takes a struct: https://docs.lucee.org/reference/functions/structkeyarray.html Why does Lucee do this shit? 😐
And given all this... what's the testbox-idiomatic way of testing for a query column's existence? (portably)
b
I wouldn't say testbox has one, though it's not a bad idea.
a
I thought it was nice that
toHaveKey
seemed to be a generic "checks for a keyish type thing"
b
We should make it detect if the input is a query and just look at the columnlist or something
1
a
Want me to raise a ticket? For now I'll just check
columnList
for my purposes.
b
Please do
a
On it.
b
It would appear if you don't provide Lucee with a struct, it will attempt to cast the input to one https://github.com/lucee/Lucee/blob/6.0/core/src/main/java/lucee/runtime/functions/struct/StructKeyArray.java#L43
a
I feel Lucee is trying to be inappropriately flexible here. But that could just be me being dogmatic about stuff like I am inclined to be 😉
(temporarily ignoring my default position of "Just do what CF does for goodness sake. Don't try to 'improve' things")