How to migrate from TypeRegistryConfigurer?

[ian-pascoe]

Right now we are on cucumber v6.11 and we would like to upgrade to v7. We cannot use the @ParameterType annotation because our regex is derived from a collection of constants at runtime. TypeRegistryConfigurer allowed us to use the derived value as a parameter type like so:

   @Override
    public void configureTypeRegistry(final TypeRegistry typeRegistry)
    {
        final UserTypeRegistratorService userService = this.getUserService();
        final WindchillTypeRegistratorService typeService = this.getTypeService();
        final WindchillReportTypeRegistratorService reportService = this.getReportService();
        LOGGER.debug(() -> "Registering user types");
        typeRegistry.defineParameterType(new ParameterType<DriverUser>("user", userService.getCombinedTypeString(), DriverUser.class,
                userService.getCaptureGroupTranformer()));

        typeRegistry.defineDataTableType(new DataTableType(DriverUser.class, userService::getUserFromString));

        LOGGER.debug(() -> "Registering windchill types");
        typeRegistry.defineParameterType(new ParameterType<WindchillType>("type", typeService.getCombinedTypeString(), WindchillType.class,
                typeService.getCaptureGroupTransformer()));

        LOGGER.debug(() -> "Registering report types");
        typeRegistry.defineParameterType(new ParameterType<WindchillReportType>("report", reportService.getCombinedReportString(),
                WindchillReportType.class, reportService.getCaptureGroupTransformer()));
    }

How can we approach this in v7?

[mpkorstanje]

Currently there is no support for that.

Parameter types are ultimately matched against feature files. And the assumption is that feature files are known at compile time. This doesn't seem to be the case in your situation. Could you elaborate on that?

Alternatively would it be possible to use a regex that matches superset of all possible values and then at run time restrict which values are actually valid?

[ian-pascoe]

We try to implement DRY by not repeating this regex strings all over the place in our codebase so we store them in a class along with the implementation. Since the annotation only accepts a constant string expression, I can't even use a constant variable there. This breaks our implementation.

Our combined regex strings for custom types are so large that it is not feasible to have it copied in various places throughout the codebase. This will introduce vectors for human error and more maintenance.

For example, we are testing PTC Windchill and there are over 50+ object types and each one has a complex regular expression that we support in our cucumber expressions. These types are implemented via a WindchillType class that also is instantiated with it's associated regular expression. It would be ideal to be able to combine all the regexes at runtime for us.

[mpkorstanje]

It sounds like implementing your own Backend would be the correct solution. The documentation is a bit sparse and the interface are a bit unwieldy, but this is a stable and public part of the API. Cucumber uses backends to register step definitions, parameter types, ect for different JVM languages. And multiple backends can be used together.

Would this work for you?

package com.example;

import io.cucumber.core.backend.Backend;
import io.cucumber.core.backend.Glue;
import io.cucumber.core.backend.ParameterTypeDefinition;
import io.cucumber.core.backend.Snippet;
import io.cucumber.core.runtime.BackendSupplier;
import io.cucumber.cucumberexpressions.ParameterType;

import java.net.URI;
import java.util.Collection;
import java.util.Collections;
import java.util.List;

public class MyBackendSupplier implements BackendSupplier {

  @Override
  public Collection<? extends Backend> get() {
    return Collections.singletonList(new MyBackend());
  }

  static class MyBackend implements Backend {

    @Override
    public void loadGlue(Glue glue, List<URI> list) {
      glue.addParameterType(new MyParameterType(new ParameterType<DriverUser>(...)));
      glue.addParameterType(new MyParameterType(new ParameterType<WindchillType>(...)));
      glue.addParameterType(new MyParameterType(new ParameterType<WindchillReportType>(...)));
    }

    @Override
    public void buildWorld() {
      // no-op
    }

    @Override
    public void disposeWorld() {
      // no-op
    }

    @Override
    public Snippet getSnippet() {
      return null;
    }
  }

  static class MyParameterType implements ParameterTypeDefinition {

    private final ParameterType<?> parameterType;

    MyParameterType(ParameterType<?> parameterType) {
      this.parameterType = parameterType;
    }

    @Override
    public ParameterType<?> parameterType() {
      return parameterType;
    }

    @Override
    public boolean isDefinedAt(StackTraceElement stackTraceElement) {
      // You'll want to implement something here that is true when ever
      // a stack trace element is in the captureGroupTranformer used in the
      // parameter type
      return false;
    }

    @Override
    public String getLocation() {
      // Return the string representation of a captureGroupTransformers location.
      // See java doc.
      return null;
    }
  }
}

Cucumber uses SPI to discover back-ends. So MyBackendSupplier must be registered in META-INF/services/io.cucumber.core.runtime.BackendSupplier.

com.example.MyBackendSupplier

[ian-pascoe]

I'm not familiar with SPI, how could I set that up with maven? Also, can this be used with the OOTB implementation for hooks, scenario context, etc?

[mpkorstanje]

I'm not familiar with SPI, how could I set that up with maven?

You'll want to read https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html.

But tl;dr: Depending on if you run cucumber as an application or as test, create either one of these files:

• src/test/resources/META-INF/services/io.cucumber.core.runtime.BackendSupplier
• src/main/resources/META-INF/services/io.cucumber.core.runtime.BackendSupplier

And add the fully qualified name of your BackendSupplier implementation in it.

Also, can this be used with the OOTB implementation for hooks, scenario context, etc?

Yes!