Editing JUnit (section)

==JUnit Extension Model==
JUnit follows the paradigm of preferring extension points over features.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model|p=121}} The JUnit team decided not to put all features within the JUnit core, and instead decided to give an extensible way for developers to address their concerns.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model|p=121}} 

In JUnit 4, there are two extension mechanisms: the Runner API and Rule API.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} There were some disadvantages to both the Runner API and the Rule API. 

A major limitation of the Runner API is that developers must implement the entire test lifecycle, even if only a specific phase is required.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} This is too complicated and heavyweight for most use cases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Another major limitation is that only one runner class can be used per test case, which makes runners non-composable.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} For example, Mockito and Parameterized runners cannot be used together within the same test class.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} 

A major limitation of the Rule API is that it cannot control the entire test lifecycle and is therefore unsuitable for certain use cases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Rules are only suitable for operations that need to run before or after test execution.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Another limitation is that class-level and method-level rules must be defined separately.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} 

In JUnit 5, the extension API is found within the JUnit Jupiter Engine.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} The JUnit Team wants to allow the developer to hook to separate stages of a test life cycle by providing a single unified extension API.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} Upon reaching a certain life cycle phase, the Jupiter Engine will invoke all registered extensions for that phase.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} The developer can hook into five major extension points:{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}}
# Test lifecycle callbacks – allow developers to execute code at specific test lifecycle phases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Test Life Cycle Callbacks|pp=124-126}}
# Test instance post-processing – enables developers to hook into the test instance creation phase using the <code>TestInstancePostProcessor</code> interface.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Test Instance Post-Processing|pp=126-127}}
# Conditional test execution – allows tests to run only if certain conditions are met.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Conditional Test Execution|p=127}}
# Parameter resolution – allows parameters to be injected into test methods or constructors.
# Exception handling – allows developers to modify test behavior in response to exceptions instead of failing the test outright.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Exception Handling|p=129}}