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.

Reply via email to