Non-static method support for dynamic parameter generation about testparameterinjector HOT 10 CLOSED

Hi!

Coincidentally, we had a similar feature request internally in google last month. In their use case, they wanted to call a method from an abstract base class:

abstract class TestBase {
  abstract List<String> fooList();
}

class MyTest extends TestBase {
  @TestParameter(provider=MyProvider.class)
  String foo;

  @Override List<String> fooList() { ... }
}

where MyProvider needs to know which subclass is calling so the right fooList() can be used.

Is inheritance also your use case?

Note that it is virtually impossible to rely on anything that is provided by JUnit, such as @Before and @Rule because the test instances can only be constructed AFTER the test parameters are known. Inheritance is an exception because you don't need any of the JUnit stuff to make it work.

The plan for the internal feature request would be to add a Context type to TestParameterValuesProvider.provideValues():

abstract class ContextAwareTestParameterValuesProvider implements TestParameterValuesProvider {
  
  abstract List<?> provideValues(Context context); // new

  @Override public final List<?> provideValues() {
    throw new UnsupportedOperationException("Should never be called");
    // because TestParameterInjector checks for this subtype first
  }

  // Pre-existing method for changing the string representation of the value
  @Override public final TestParameterValue value(@Nullable Object wrappedValue) { ... }
}

  @AutoValue
  static abstract class Context {
    abstract List<Annotation> otherAnnotationsOnType();

    abstract Class<?> testClass();
  }

In the above example, context.testClass() can then be used to create a new instance of it and call fooList().

Would this solution also work for your use case?

from testparameterinjector.

Yes, inheritance is in our use case as well. The above solution might work. What's the best way to test it locally?

from testparameterinjector.

What's the best way to test it locally?

If you want to test the above solution, that's not possible yet because it hasn't yet been implemented. But this thread is a good extra reason to not wait too long implementing it.

from testparameterinjector.

Thanks, we are migrating all our tests to use TestParameterInjector and this would help us wrap up the last few remaining test suites. Let us know when you would have it ready. Thanks!

from testparameterinjector.

Thanks for implementing this @nymanjens. Would you be publishing a new version for us to consume? Thanks!

from testparameterinjector.

Yes, I plan to release a new version shortly

from testparameterinjector.

Yesterday, I released v1.15, which contains this change. It is showing up on the Maven repository now: https://mvnrepository.com/artifact/com.google.testparameterinjector/test-parameter-injector

So you should be able to start using this.

from testparameterinjector.

Great, thanks, we'll try it out this week

from testparameterinjector.

@nymanjens This solution worked for us, thanks for getting this in!

Based on the javadoc, are you planning to deprecate the previous version of the provider?https://google.github.io/TestParameterInjector/docs/latest/com/google/testing/junit/testparameterinjector/TestParameterValuesProvider.html

from testparameterinjector.

Based on the javadoc, are you planning to deprecate the previous version of the provider?

Correct, but since this is an open source project, it'll probably stay around (deprecated) forever / a very long time.

from testparameterinjector.