that's what i meant by "reflection" or as you suggest eval(). I guess the
point is that if the language can support some way of taking the string
value and turning it automatically into a traversal in that GLVs style then
we should do that.
On Thu, Sep 14, 2017 at 4:45 PM, Daniel Kuppitz <m...@gremlin.guru> wrote:
> For unparameterized queries it can probably be as easy as:
>
> @given("the traversal of")
> def translate_traversal(step):
> g = step.context.g
> step.context.traversal = eval(step.text)
>
>
> Cheers,
> Daniel
>
>
> On Thu, Sep 14, 2017 at 1:39 PM, Daniel Kuppitz <m...@gremlin.guru> wrote:
>
> > That's great stuff. I haven't used Cucumber / Gherkin for years, but I
> > really like the BDD approach.
> >
> > and then you can look at the GLV Gremlin translations specifically here:
> >> https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/grem
> >> lin-python/src/main/jython/radish/count_features_step.py#L34-L46
> >
> >
> > This part is the only thing that looks weird to me. You're basically
> > writing every query twice; is there really no easier way to do that?
> >
> > Cheers,
> > Daniel
> >
> >
> > On Thu, Sep 14, 2017 at 1:17 PM, Stephen Mallette <spmalle...@gmail.com>
> > wrote:
> >
> >> I've brought this issue up in the past and had suggested some options I
> >> had
> >> in mind but now I've finally put the basics of those ideas in place so I
> >> figured I'd start a fresh thread. Recall that the issue at hand is that
> we
> >> don't have a test suite for GLVs as gremlin-test is bound to the JVM. We
> >> have some tricks that let us test gremlin-python with it but those
> tricks
> >> won't work for every language and we now have the first language in
> >> gremlin-dotnet and upcoming gremlin-javascript which won't support it
> >> (yes,
> >> i know that gremlin-javascript can run on the jvm but there are issues
> >> with
> >> getting it all to work with the test framework that make it unduly
> >> complicated).
> >>
> >> On other threads I offered the idea that we look to use Gherkin to write
> >> general Gremlin test specifications, which then could be read and
> >> processed
> >> by the wide variety of test frameworks that can read that format - there
> >> tend to be Gherkin processors in just about every language - for
> example,
> >> see:
> >>
> >> https://cucumber.io/
> >>
> >> I just created this issue:
> >>
> >> https://issues.apache.org/jira/browse/TINKERPOP-1784
> >>
> >> and pushed this branch:
> >>
> >> https://github.com/apache/tinkerpop/tree/TINKERPOP-1784
> >>
> >> which demonstrates how this works with gremlin-python. The basic anatomy
> >> of
> >> this setup involves this new directory in gremlin-test:
> >>
> >> https://github.com/apache/tinkerpop/tree/TINKERPOP-1784/grem
> >> lin-test/features
> >>
> >> It contains the Gherkin .features files. These are the test
> >> specifications.
> >> They are written using gremlin-java as the "model" language. GLVs will
> >> then
> >> need to write some infrastructure to process these Gherkin files. The
> key
> >> to making this "easy" to implement will lie in our abiilty to keep the
> >> assertions we want to have relatively simple. The more simplistic the
> >> language in the Gherkin .feature files the easier the job it will be for
> >> GLVs to build their infrastructure. Of course, once that infrastructure
> is
> >> in place, the GLV developer just has to write the GLV version of the
> >> Gremlin specified in the .feature file. So you can look at all the
> >> "infrastructure" code here in this pair of files:
> >>
> >> https://github.com/apache/tinkerpop/tree/TINKERPOP-1784/grem
> >> lin-python/src/main/jython/radish
> >>
> >> and then you can look at the GLV Gremlin translations specifically here:
> >>
> >> https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/grem
> >> lin-python/src/main/jython/radish/count_features_step.py#L34-L46
> >>
> >> I think this approach works pretty well and solves our general problems
> >> for
> >> GLV testing. There is some pain up front in implementing the
> >> "infrastructure" but after that new Gremlin tests added to .feature
> files
> >> just need to translated in the GLV. I suppose we could "automate" a good
> >> portion of the translation with reflection of some sort. Anything else
> >> could just be handled manually.
> >>
> >> Not sure if we need to use this new model to wholly replace the old one.
> >> The process test suite has its place in helping graph database providers
> >> test their stuff. I also imagine that introducing this approach in that
> >> context would create a breaking change which we would then need to push
> >> off
> >> to 3.4.0. I suppose that gives us time to think, but for now it might
> not
> >> be best to conflate the two and just treat them as separate aspects of
> the
> >> test suite.
> >>
> >> Anyway - it's important we settle on an approach to testing as we really
> >> shouldn't do a GA release of the Gremlin .NET GLV without getting the
> test
> >> suite solid. please yell if you have any ideas or feedback on this
> >> approach.
> >>
> >
> >
>
