The model is nice, but as you say, it doesn't work off the JVM. I think the test model should try to be less tied to the JVM and sketchy ScriptEngine support. We already have that trouble with Jython which is bound to Python 2.x. I'd prefer to think of that model as more of an "integration" test which yields a good end-to-end test and something we can use as we need to when the support is there.
On Mon, Sep 26, 2016 at 12:12 PM, Marko Rodriguez <[email protected]> wrote: > 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. > >
