Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way for 3rd party to intercept method param injection #1164

Open
juherr opened this issue Sep 22, 2016 · 3 comments
Open

Add a way for 3rd party to intercept method param injection #1164

juherr opened this issue Sep 22, 2016 · 3 comments

Comments

@juherr
Copy link
Member

juherr commented Sep 22, 2016

From jmockit/jmockit1#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.

@rliesenfeld
Copy link

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.

@nitinverma
Copy link
Contributor

nitinverma commented Sep 23, 2016

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.

@juherr
Copy link
Member Author

juherr commented Sep 24, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants