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

Intercept Exceptions in @BeforeEach for Handling before @AfterEach #3411

Closed
fleytman opened this issue Aug 3, 2023 · 6 comments
Closed

Intercept Exceptions in @BeforeEach for Handling before @AfterEach #3411

fleytman opened this issue Aug 3, 2023 · 6 comments

Comments

@fleytman
Copy link

fleytman commented Aug 3, 2023

Problem:

  1. In JUnit 5, there is a difficulty in handling exceptions that occur in the @BeforeEach method and an inability to intercept them before calling the @AfterEach method, even if an exception occurred in the test.
  2. The @AfterTestExecutionCallback extension allows handling exceptions that occur during the execution of the @Test method (@Test method). However, this extension doesn't work for the @BeforeEach method, thus providing no means to intercept exceptions in this setup phase.

I have a concrete example demonstrating the issue with my code and its output. You can find it here: Code Example and Output.

Consequences:

  1. The inability to intercept and handle exceptions in @BeforeEach before calling the @AfterEach method can lead to redundant logging and capturing screenshots. For instance, if the @AfterEach method involves finalization activities, such as resetting the application or cleaning up data, logs and screenshots might be taken not at the moment of the failure but much later.
  2. In the case of mobile applications, this may result in screenshots being taken not at the moment of the application crash (at the crash site) but at the starting screen or another state of the application after the finalization activities, making it more difficult to identify and analyze the exact cause of the crash.

Desired Solution:

Introduce a new extension or callback method in JUnit 5 that allows handling exceptions in both @BeforeEach and @Test methods before calling @AfterEach.
This proposed solution would enable developers to react to exceptions from @BeforeEach and perform additional actions before calling @AfterEach, enhancing the flexibility of managing resources and logic for each test scenario, as well as ensuring more reliable logging and capturing screenshots at the point of failure.

By implementing this enhancement, JUnit would become an even more powerful tool for developing and managing test scenarios, providing improved error handling, and simplifying the creation of reliable test suites.

@marcphilipp
Copy link
Member

marcphilipp commented Oct 13, 2023

@fleytman LifecycleMethodExecutionExceptionHandler should allow handling exceptions thrown from @BeforeEach methods. Have you tried that?

@github-actions
Copy link

If you would like us to be able to process this issue, please provide the requested information. If the information is not provided within the next 3 weeks, we will be unable to proceed and this issue will be closed.

@fleytman
Copy link
Author

fleytman commented Nov 8, 2023

I think so, but I'll run a couple more experiments in the next couple weeks to be sure.

@marcphilipp
Copy link
Member

Optimistically closing. @fleytman Please comment here if it turns out not to work for you after all.

@marcphilipp marcphilipp closed this as not planned Won't fix, can't repro, duplicate, stale Nov 17, 2023
@fleytman
Copy link
Author

fleytman commented Nov 20, 2023

@marcphilipp thx, your method is working

override fun handleBeforeEachMethodExecutionException(context: ExtensionContext?, throwable: Throwable?) {
  println(context?.executionException?.toString())
  println("handleBeforeEachMethodExecutionException")
  super.handleBeforeEachMethodExecutionException(context, throwable)
}

But i have a question why println(context?.executionException?.toString()) is Optional.empty?

@sbrannen
Copy link
Member

But i have a question why println(context?.executionException?.toString()) is Optional.empty?

That's explained in the Javadoc for that method:

Returns:
an Optional containing the exception thrown; never null but potentially empty if test execution has not (yet) resulted in an exception

Since a LifecycleMethodExecutionExceptionHandler is allowed to swallow an exception, there is no guarantee that the execution will result in an exception.

That's why the exception to handle is passed directly to the handleBeforeEachMethodExecutionException() method.

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