search

neo4j-contrib / sql2cypher

Experimental SQL to Cypher Transpiler using jooq and cypher-dsl
Apache License 2.0
26 stars 1 forks source link

Implement some test / report that checks which jOOQ API / Cypher DSL API is already covered by tests #22

Closed lukaseder closed 7 months ago

lukaseder commented 1 year ago

The jOOQ integration tests have some agents that run e.g. during the tests of the parser to make sure all (most) jOOQ API is covered in some way by the parser. That way, when I add new jOOQ API, e.g. for some SQL function, I will not forget to add support for it also in the parser. This doesn't guarantee I'm parsing all the possible syntaxes correctly, but at least it guarantees I don't forget thinking about it.

Such an agent would be useful as well for this module. It could run in 2 ways:

The benefit is obvious. As both jOOQ and Cypher DSL evolve, we will at least have feedback on what needs to be done here, but we will probably forget in 1 year.

Testing the jOOQ side

As far as the jOOQ side is concerned, it's probably easiest to just enhance the jOOQ integration tests (eventually) with this check. I'll then make some quarterly (?) reports here on what new SQL features could be covered.

Testing the Cypher DSL side

See description above.

jexp commented 1 year ago

Would that use just a code-coverage tool (for a filtered subset of the API/DSL)?

Or a manual check/list of the things that we might be able to cover?

lukaseder commented 1 year ago

In jOOQ, there's a single DSL API entry point (org.jooq.impl.DSL, see also https://github.com/neo4j-contrib/cypher-dsl/issues/573), and all of the DSL methods throughout the API are annotated with @Support (to list dialect support). That @Support annotation is used for documentation by users, by a compiler plugin that prevents accidental access to unsupported syntax, and by the test suite for various things, including discovering the implicit grammar encoded in the BNF.

As such, we can attach the agent to all methods that are annotated @Support and check if they're all called though some code path. That's probably more precise than some blunt code-coverage tool, but I haven't evaluated all of those, so perhaps they will suffice?

In any case, there also needs to be a list of exceptions, i.e. Cypher syntax that can't be represented in SQL, which won't be covered by these tests.

michael-simons commented 7 months ago

Kamino closed and cloned this issue to neo4j/neo4j-jdbc