[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437257#comment-15437257
]
Sandeep Tamhankar commented on TINKERPOP-1278:
----------------------------------------------
I understand the desire to leverage existing testing infrastructure to exercise
various language variants, but my impression from this thread is that the tests
are actually testing a mix of variant and driver, since you're testing the
results that come back from the Gremlin server.
If you want to focus on testing the variant itself, I’d think you’d want a
bunch of queries written in the Ruby variant along with expected “byte code”
(which may be a string) that will be sent. In this simple form, you’d have to
duplicate each test for every variant. To avoid that, you could write the
queries in a DSL and have a test tool convert it to the right query in the
desired language, run it, and then compare result with the expected “byte
code”. But that reasoning can be recursive — how do you know the tool
generating the queries in Ruby (for example) is doing it right?
That skirts the issue presented in this Jira: you need some tests that make
sure that results are coerced into native types properly (e.g. driver tests). I
haven’t done a lot with JRuby myself — wrote one native module for Kerberos
support in the DataStax Enterprise Ruby driver, but that’s about it. In my
context, the logic flow was really controlled by Ruby code, and there were
callouts to JRuby for specific things. The way this ticket talks about
ProcessXXXSuite, it sounds like ProcessXXXSuite is the master…like running a
Java program and embedding Ruby in it, rather than the other way around. Sounds
reasonable.
I'm not saying end-to-end tests aren't useful, but I feel like this ticket is
focused on variant testing...so it should purely test variants.
> Implement Gremlin-Python and general purpose language variant test
> infrastructure
> ---------------------------------------------------------------------------------
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Affects Versions: 3.2.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model
> presented in
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
> Moreover, on every {{mvn clean install}}, the code for these variants is
> generated.
> Given the desire to separate language variants from language drivers, I think
> that a language driver for each variant above should be "plugable." Moreover,
> we should provide one driver implementation for each -- simple GremlinServer
> REST.
> {code}
> gremlin-variants/
> gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
> gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
> gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we
> have to implement each {{g_V_out_repeatXasXaXX}} test case in
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to
> convert all those tests from Gremlin-Java to the respective host language?
> However, even if we do that, we still have the problem of how to test the
> returned results.
> I think what we should test the returned results using the JVM. For instance,
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a
> massive headache. All we have to do is create a {{GraphProvider}} that uses
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java // manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
