Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.5.2
-
None
Description
The process by which gherkin tests run for GLVs involves a generate.groovy script which examines the feature files, extracts Gremlin and passes it through a specially configured GremlinGroovyScriptEngine to get traversal bytecode. The special configuration it receives is the VarAsBindingASTTransformation which has the important job of detecting variables in the Gremlin being evaluated and replacing them with Bindings.of() declarations which will then capture those in the bytecode. When captured in the bytecode it becomes possible for a Translator to regenerate the script with variable names in the native language that is being tested.
The problem that arises is that the VarAsBindingASTTransformation has to make a guess at the type the variable represents. Consider mergeV() which has both Map and Traversal overloads. VarAsBindingASTTransformation chooses Map by default. The choice really isn't all that relevant except when it comes to translations in a type-safe language like C# where the guess choice of Map leads to a translation of mergeV((IDictionary<object,object>) __.identity()) which obviously leads to a casting problem.
This problem seems reasonably tied to C# and specific to this odd use case we have with testing. Most users would likely not be translating in this fashion which is why it hasn't come up. They certainly wouldn't be looking to use VarAsBindingASTTransformation in their code. Since it is a testing problem perhaps a solution would be to better bind VarAsBindingASTTransformation to the Gherkin framework and maybe use the variable names to hint at what the type should be. They are already somewhat named according to type in some respects, but it is probably not yet fully consistent.