Hi,
The way I have it set up currently is that for each GLV there is a
XXXTranslator.
In particular a ScriptTranslator (a sub-interface of Translator) will turn
Bytecode into a String.
* If its PythonTranslator, it will turn bytecode into a Python string
representing that traversal.
https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonTranslator.java
<https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonTranslator.java>
* If its GroovyTranslator, it will turn bytecode into a Groovy string
representing that traversal.
https://github.com/apache/tinkerpop/blob/master/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GroovyTranslator.java
<https://github.com/apache/tinkerpop/blob/master/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GroovyTranslator.java>
Then from there you can see how it ties into the test suite:
https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonProcessStandardTest.java
<https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonProcessStandardTest.java>
https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonProvider.java#L158
<https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223/PythonProvider.java#L158>
- I check BOTH that GraphSON translation and Python translation
work for each traversal in the ProcessXXXTestSuite.
In this way, we really don’t need the gremlin-groovy-test/
ProcessStandard/ComputerSuite anymore as each Java traversal in
ProcessStandard/ComputerSuite can be turned into the String representation for
any GLV.
Is this sufficient? Note that this model ONLY works for languages that have a
JVM ScriptEngine implementation — e.g. Ruby, Clojure, Scala, JavaScript,
Python, Groovy, PHP, R, etc.
https://en.wikipedia.org/wiki/List_of_JVM_languages
<https://en.wikipedia.org/wiki/List_of_JVM_languages>
Marko.
http://markorodriguez.com
> On Sep 21, 2016, at 7:13 AM, Stephen Mallette <[email protected]> wrote:
>
> I was thinking about how to test our GLVs (existing and more importantly
> future ones to come) and how to best leverage our existing test
> infrastructure. We have about 600 "process" suite tests (i.e. test methods
> that contain assertions for a particular traversal). Those tests are
> re-used in a variety of different ways to validate traversal operations
> over graph computer, groovy, bytecode, etc. Together those tests give us
> confidence that Gremlin "works".
>
> If we're content with the logic the bytecode processing is sound, then a
> GLV should be satisfied that it will work if it produces compliant
> bytecode. Therefore, the validation of GLV compliance with Gremlin really
> just means validating that it produces good bytecode.
>
> If you're still with that logic, the perhaps a good way to provide GLVs a
> platform independent set of compliance tests would be to include a body of
> Cucumber specs in our gremlin-test suite. Cucumber is supported in just
> about every language and implementing a parser in a language that isn't
> supported is pretty simple.
>
> The spec could take the form of:
>
> Feature: Filter Steps
> Scenario: Dedup Step
> Given a Java traversal of g.V().dedup()
> When translated to the GLV native language
> Then the Bytecode representation should be [[], [V(), dedup()]]
>
> then all the GLV has to do is implement the Cucumber steps to process the
> spec. Processing would be pretty simple, just use the Java traversal (which
> will be String representation going into cucumber) to lookup the GLV
> representation of the traversal and then use that to generate the Bytecode
> you would submit to the server and assert it as part of the "Then".
>
> btw, i'm not saying that this approach should replace GLV unit tests or
> that a GLV shouldn't have integration tests directly to Gremlin Server.
> Using Cucumber just provide a means for centralizing GLV compliance on
> Bytecode which should be enough to give us reasonably solid assurance that
> that Gremlin semantics are being met.
