Package org.apache.tinkerpop.gremlin.features

Interface World

public interface World
This interface provides the context the test suite needs in order to execute the Gherkin tests. It is implemented by graph providers who wish to test their graph systems against the TinkerPop test suite. It is paired with a test that uses the Cucumber test runner (i.e. @RunWith(Cucumber.class)) and requires a dependency injection package (e.g. guice) to push an instance into the Cucumber execution.

  • Field Details

    • GRAPHCOMPUTER_TAG_FILTER

      static final String GRAPHCOMPUTER_TAG_FILTER
      Tag filter string for tests that will not run for tests using withComputer(). This is a helpful start point to filtering away tests using the "tags" argument for CucumberOptions.
      See Also:

  • Method Details

    • getGraphTraversalSource

      GraphTraversalSource getGraphTraversalSource(LoadGraphWith.GraphData graphData)
      Gets a GraphTraversalSource that is backed by the specified LoadGraphWith.GraphData. For null, the returned source should be an empty graph with no data in it. Tests do not mutate the standard graphs. Only tests that use an empty graph will change its state.

    • getMultiLabelGraphTraversalSource

      default GraphTraversalSource getMultiLabelGraphTraversalSource()
      Gets a GraphTraversalSource configured for multi-label support (ZERO_OR_MORE vertex label cardinality). This source is used by @MultiLabel tagged scenarios that require label mutation operations such as addLabel() and dropLabel(). The default implementation delegates to getGraphTraversalSource(GraphData) with null which works for embedded graphs that already have multi-label cardinality configured. Remote implementations should override this to connect to a dedicated multi-label traversal source.

    • beforeEachScenario

      default void beforeEachScenario(io.cucumber.java.Scenario scenario)
      Called before each individual test is executed which provides an opportunity to do some setup. For example, if there is a specific test that can't be supported it can be ignored by checking for the name with scenario.getName() and then throwing an AssumptionViolatedException.
      Parameters:
      scenario -

    • afterEachScenario

      default void afterEachScenario()
      Called after each individual test is executed allowing for cleanup of any open resources.

    • changePathToDataFile

      default String changePathToDataFile(String pathToFileFromGremlin)
      Called when g.io() is encountered in the Gherkin tests and allows the path to the data file to referenced to be changed. The default path will look something like: data/file.extension and will match one of the standard TinkerPop data files associated with the test framework. If the files need to be located somewhere else for a particular provider, this method can alter the path as needed.
      Parameters:
      pathToFileFromGremlin - the path to a data file as taken from the Gherkin tests

    • convertIdToScript

      default String convertIdToScript(Object id, Class<? extends Element> type)
      Converts a graph element's T.id to a form that can be used in a script parsed by the grammar. For example, if the graph has numeric identifiers the default implementation of id().toString() would return "0" which would be interpreted by the grammar as a number when parsed in g.V(0). However, a graph that used UUID for an identifier would have a representation of "1c535978-dc36-4cd2-ab82-95a98a847757" which could not be parsed by the grammar directly as g.V(1c535978-dc36-4cd2-ab82-95a98a847757) and would need to be prefixed and suffixed with double or single quotes. Therefore, this method would be overridden for that graph to perform that function.

    • useParametersLiterally

      default boolean useParametersLiterally()
      Determines if the test should use parameters literally or treat them as variables to be applied to the script. By default, they are treated literally.

    • handleErrorMessageAssertion

      default boolean handleErrorMessageAssertion(String comparison, String expectedMessage, Throwable actualException)
      Allows for some flexibility in error message assertion, where the provider can handle assertions themselves. Providers should use standard assertion logic as they would with tests. Note that if this method is called, then the exception has happened and that the only point of concern for assertion is the message. Providers can not use this method as a way to avoid throwing an exception in the first place. TinkerPop tries to not be too prescriptive with error messages and while we recommend providers conform to our messages it is not required.
      Returns:
      true if the assertion was handled and false if default handling should be engaged