Status Quo

The extension registration model is currently a work in progress and needs to be revisited to make sure it aligns with the needs of the extension authors and the community at large.

Topics to Review and Revisit

• TestExtension vs. ExtensionPoint
  • What purpose does TestExtension serve since the introduction of ExtensionPoint? Do we need two maker interfaces for extensions?
• ExtensionPoint vs RegisteredExtensionPoint
• ExtensionPointSorter
  • Why limit sorting to implementations of ExtensionPoint? Why not allow any type of TestExtension to be sorted?
• ExtensionRegistry vs. TestExtensionRegistry
  • At the very least, the names are both misleading and confusing.
  • An ExtensionRegistry currently allows one to register only instances of ExtensionPoint. So why isn't it called an ExtensionPointRegistry?
• ExtensionPoint.Position
  • Why is Position specific to ExtensionPoint?
  • An extension author would likely never want an extension to be invoked "in the middle" (i.e., in the DEFAULT position) alongside user code. So what purpose does DEFAULT serve?
  • Position defines only 5 options for extension authors. Why should JUnit be so restrictive? Why not allow any numerical ordering (e.g., the entire range of integers, perhaps other than 0) beyond the hard coded 5 current values?
  • Consider a solution such as @Order that can be reused across multiple use cases within the framework.
• Verify (via appropriate testing) that the current algorithm properly sorts extensions when multiple extensions exist within test class hierarchies and within a given extension execution context.
• The current extension model allows additional extensions to be registered programmatically via the ExtensionRegistry; however, there is no mechanism for overriding extensions that have already been registered (e.g., in superclasses).
  • We need a way to override extensions that have been registered in an enclosing context.