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

Intialization of Knot.x w/o variable in method/class signature #54

Open
tMaxx opened this issue May 12, 2020 · 0 comments
Open

Intialization of Knot.x w/o variable in method/class signature #54

tMaxx opened this issue May 12, 2020 · 0 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@tMaxx
Copy link
Contributor

tMaxx commented May 12, 2020

Background
Currently, we initalize Knot.x instance from provided configuration only when an appropriate variable type is present in a given class, or on a given method. As a result, tests that need to interact with Knot.x indirectly will have some unneeded code inside - for example we need to test a service that interacts with Knot.x, but we don't need to extend it in any way, yet we will still need to declare Vert.x variables and contexts.

Expected behavior
There should be a way to force initalization of Knot.x instance without the need to declare all variables (Vert.x instance and test context). This can be potentially done in two ways:

  1. Add an explicit flag/annotation that will force initialization of Knot.x when there are no method/class variables present;
  2. Detect following: presence of @KnotxApplyConfiguration on method/class and lack of Vert.x variables in method/class, and then initalize Knot.x instance.

Also:

  • We should stop requiring user to put both Vert.x and test context in order to use configuration injection.
  • If user doesn't explicitly need to fail the test that uses Knot.x, assume that the run was successful and act accordingly.
  • It should be possible to implement this in an orderly fashion by using JUnit's store mechanism.
  • Provide some examples for implemented solution, and extend the documentation to reflect the changes.

Things to keep in mind

  • Backward compatibility; all changes must be transparent to existing functionalities, and opt-in in nature. If we decide to break compatibility, there should be some additional checks put in place to warn user of the changed behavior.
  • Explore the possibility to backport these changes into previous versions (specifically, into v1.5, as some projects still use this version).
@tMaxx tMaxx added enhancement New feature or request help wanted Extra attention is needed labels May 12, 2020
@tMaxx tMaxx changed the title Support intialization of Knot.x w/o variable in method/class signature Intialization of Knot.x w/o variable in method/class signature May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant