Nice! Gherkin will make our lives easier with a growing number of GLVs.
We should find a way to define the different features supported by each
GLV, as it's reasonable to have different maturity levels per GLV (ie:
lambdas support, traversal strategy, ...). I don't know if it will be
beneficial to do it in the Gherkin files or within each GLV implementation.
Also, we should consider the process of rolling out a new method / class in
the java implementation, how that could affect each GLV.
On Thu, Sep 14, 2017 at 11:12 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:
> 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.
> > >>
> > >
> > >
> >
>
