Re: [DISCUSS] GLV Test Suite

Makes sense, as long as we have the basic logic nailed down for the steps / parameters / results, we can continue adding scenarios afterwards (new scenarios with the same step structure should work in any language). On Wed, Nov 8, 2017 at 1:49 PM, Stephen Mallette wrote: >

Re: [DISCUSS] GLV Test Suite

I've been away for a few days on vacation, but before I left, I made some pretty decent progress on the remaining tests and I'm finding less and less of my time being focused on the test logic and more and more of it on the translation of the tests themselves. I'm starting to feel comfortable that

Re: [DISCUSS] GLV Test Suite

I've created TINKERPOP-1827 to track the progress of the test suite runner for Gremlin .NET. I have a working gherkin-based runner that executes the steps (parsing gremlin groovy / parameters / results) as defined in the TINKERPOP-1784 WIP branch.

Re: [DISCUSS] GLV Test Suite

Ok. Going back to my initial comment regarding enums: don't mind, I've included the possibility to use enums on the C# parser. On Mon, Oct 30, 2017 at 7:15 PM, Stephen Mallette wrote: > I guess there wouldn't be a problem with that, though having it the way it > works now

Re: [DISCUSS] GLV Test Suite

I guess there wouldn't be a problem with that, though having it the way it works now was a nice check to ensure that the ScriptEngine was configured properly. I guess that shouldn't be the focus on this body of tests though. We should be more concerned that the elements of the Gremlin language

Re: [DISCUSS] GLV Test Suite

I see that for most languages using bytecode to native language translator would be the easiest solution. In the case of the JavaScript GLV, it would be fairly straightforward to implement (and I plan to do so!). In the case of C#, being more strict regarding typing than java, it would be an

Re: [DISCUSS] GLV Test Suite

I can't help thinking that perhaps non-JVM languages need to leverage bytecode to make traversal building easier. We already have an established pattern for converting bytecode into Traversals and while it is different for each language, it's generally governed by the Translator interface. Note

Re: [DISCUSS] GLV Test Suite

I've been looking over the current test scenarios on the TINKERPOP-1784 branch, with the C# GLV test suite in mind, and oh man that's an impressive amount of scenarios! So far, I have a suggestion. Instead of Scenario: g_V_fold_countXlocalX Given the modern graph And the traversal of

Re: [DISCUSS] GLV Test Suite

Just a quick update on this item - it continues Went down a bad path earlier in the week and ended up shelving a lot of work - ended up just coded into a corner. Anyway, I've not really changed much in the implementation, but I've still not reached a point where the addition of a new

Re: [DISCUSS] GLV Test Suite

I did some pretty heavy refactoring to the python test logic (altered a bit by some revision of the gherkin feature file language) and the result is a much more simplified test logic file:

Re: [DISCUSS] GLV Test Suite

Great progress! I like how you avoided using ids, even if it adds some complexity to the transformation required. The Python step definitions are still quite simple, I think it would be mostly the same on the rest of the languages. On Thu, Sep 28, 2017 at 1:45 PM, Stephen Mallette

Re: [DISCUSS] GLV Test Suite

Just another update on progress with the test suite. The language of the .feature files is getting slightly more complex as I try to translate more and more of our Java process suite tests into the language of the gherkin files. You can see here where I've added the ability to include parameters:

Re: [DISCUSS] GLV Test Suite

I was able to build a proof of concept for a Gherkin-based test runner in C#, that takes the proposed count and select features and runs them using C# step definitions. It uses the Gherkin parser

Re: [DISCUSS] GLV Test Suite

Thanks for the update. I'm trying to keep the test language as simple as possible so that we don't need an overly complicated test implementation. Hopefully that will help make the .NET approach as easy as possible. On Fri, Sep 22, 2017 at 8:20 AM, Jorge Bay Gondra

Re: [DISCUSS] GLV Test Suite

I've been looking into Gherkin support for .NET: SpecFlow, the cucumber implementation for .NET , does not support .NET Core platform (we use .NET Core build tools for the .NET GLV) and only supports .NET Framework. >From what I can see

Re: [DISCUSS] GLV Test Suite

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

Re: [DISCUSS] GLV Test Suite

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

Re: [DISCUSS] GLV Test Suite

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 wrote: > That's great

Re: [DISCUSS] GLV Test Suite

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/ >

[DISCUSS] GLV Test Suite

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