[TINKERPOP-2443] Improve testing of Translator instances for non-JVM languages with focus on Python as a model

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Done
• Affects Version/s: 3.4.8
• Fix Version/s: 3.5.0
• Component/s: python, test-suite, translator
• Assignee: Stephen Mallette
• Reporter: Stephen Mallette
• Created: 09/Oct/20 14:19
• Updated: 03/Nov/20 13:55
• Resolved: 02/Nov/20 16:30

Description

It's easy to test a translator like GroovyTranslator because it runs on the JVM and can hook directly into the standard gremlin-test suite. Off the JVM it's a bit harder because you need a way to run the generated code in the language environment you generated for. So, for PythonTranslator we would need to hook into the Gherkin tests somehow. I was thinking we could generate a python file on builds that runs through the Gherkin tests to produce the translated version of the Gremlin. That would become a lookup by the test scenario name when executing the Radish tests. In that way we get to test if the translated Gremlin compiles and executes natively. That might also rid ourselves of the "manual" translation we do now in a piece of code like feature_steps.py which has to string parse Gremlin to produce the compliable Python.

Issue Links

• is duplicated by: TINKERPOP-2404 Generalize testing for Translator implementations
• is related to: TINKERPOP-2458 Bytecode Bindings lost when followed by a child traversal
• relates to: TINKERPOP-2442 Make Translators that work in Java part of gremlin-core