Testng: Add a way for 3rd party to intercept method param injection

Created on 22 Sep 2016  ·  3Comments  ·  Source: cbeust/testng

From https://github.com/jmockit/jmockit1/issues/337

It should work with and without dataprovider.

@rliesenfeld Any wishes on a future provided API?

@nitinverma is open to participate to the integration as he already made good job on param injection.

data-provider injection

Most helpful comment

I think the brand new JUnit 5 extension model can be a good source of inspiration. The only thing missing in JUnit 5 is a way for a 3rd-party library to automatically register those extensions, without users having to manually add "@ExtendWith" annotations to their test classes.

TestNG already has a set of extension interfaces (IExecutionListener, for example, which JMockit implements), but none similar to JUnit's ParameterResolver interface. I imagine something like this could be added.

All 3 comments

I think the brand new JUnit 5 extension model can be a good source of inspiration. The only thing missing in JUnit 5 is a way for a 3rd-party library to automatically register those extensions, without users having to manually add "@ExtendWith" annotations to their test classes.

TestNG already has a set of extension interfaces (IExecutionListener, for example, which JMockit implements), but none similar to JUnit's ParameterResolver interface. I imagine something like this could be added.

I would like to propose we should think not just about method argument injection but other augmentations/extensions that may be possible to a testing framework.

Following is a preliminary idea on generically supporting/exposing integrations:

  • Feature integrations can be introduced.
  • Feature integrations can be deprecated.
  • Feature integrations can be retracted.
  • Feature integrations may have prerequisites.
  • Feature integration's prerequisites may be versions.
  • Feature integration's prerequisites may be another integrations.
  • One product may expose multiple feature integrations.
  • Product integration is not directly dependent of other product integrations but via feature integrations.
  • User should have easy access to the list of active integrations.

Metaphor:

TestNG is a mothership and other products are pods. Pods dock in the mothership and offer bunch of features. Features get coupled or coupling waits of another features (via same pod or another) or rejected as is retracted. Once the couplings are in place mothership can engage or disengage to carryout proper functioning and course correction.

Above is just a rough outline I hope gets enriched via discussion.

I like the vision but it can be done by steps and method argument injection is the perfect candidate for the first step.

And currently, listeners are a good way for 3rd party extensions.

Was this page helpful?
0 / 5 - 0 ratings