question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Execution order of extensions changed with 1.7.0

See original GitHub issue

Since 1.7.0 some extension annotations at class level are not applied before @RegisterExtension any more.

Specifically @SetSystemProperty is using beforeEach now but used beforeAll and has been executed before @RegisterExtension annotated extension fields in the test class.

We are using DropwizardAppExtension to bootstrap an application for all tests in the test class. In our case, the application needs the system property on startup to be configured for the test.

This change has been introduced with #496.

We see our test failing with the update to 1.7.0.

The PR and associated issues refer to alignment and consistent behavior. That sounds reasonable at a first glance. My personal assumption would be that something at class level is wrapped around something at method level and is applied as a class extension.

Do you have any suggestion how a test can be configured with 1.7.0 when it uses a static class extension that needs a system property to be configured for the test. In our specific case we could try to bootstrap the application in the test method and shut it down in a finally statement. But in general that is not suitable as it should be started only once for many test methods for performance reasons.

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:1
  • Comments:11 (8 by maintainers)

github_iconTop GitHub Comments

2reactions
beatngu13commented, Apr 20, 2022

Hi @JoergSiebahn,

thanks for the feedback! 👍 So, we will first follow the aforementioned approach, where we “try to keep the current/new behavior, but make the extension additionally visible in @BeforeAll”.

PS: I only used the @Order annotation to make it more clear how the extension would behave. From the JUnit 5 user guide:

By default, test classes and methods will be ordered using an algorithm that is deterministic but intentionally nonobvious.

1reaction
beatngu13commented, Apr 14, 2022

Due to our new reset mechanism, I think we can no longer combine BeforeEach/BeforeAll. But as @Michael1993 said, we could provide a configuration option:

@TestMethodOrder(OrderAnnotation.class)
// Default execution phase BeforeEach/AfterEach.
@SetSystemProperty(key = "foo", value = "bar")
class MyTestA {

	@BeforeAll
	static void setUpOnce() {
		assertThat(System.getProperty("foo")).isNull();
	}

	@BeforeEach
	void setUp() {
		assertThat(System.getProperty("foo")).isEqualTo("bar");
	}

	@Order(1)
	@Test
	void test1() {
		assertThat(System.getProperty("foo")).isEqualTo("bar");
		// Not visible in test2() because of AfterEach reset.
		System.setProperty("foo", "baz");
	}

	@Order(2)
	@Test
	void test2() {
		assertThat(System.getProperty("foo")).isEqualTo("bar");
	}

}

@TestMethodOrder(OrderAnnotation.class)
// Alternative execution phase BeforeAll/AfterAll.
@SetSystemProperty(key = "foo", value = "bar", executionPhase = BEFORE_ALL)
class MyTestB {

	@BeforeAll
	static void setUpOnce() {
		assertThat(System.getProperty("foo")).isEqualTo("bar");
	}

	@BeforeEach
	void setUp() {
		// Before test1() "foo" = "bar", after test() "foo" = "baz".
		assertThat(System.getProperty("foo")).isNotNull();
	}

	@Order(1)
	@Test
	void test1() {
		assertThat(System.getProperty("foo")).isEqualTo("bar");
		// Visible in test2() because of AfterAll reset.
		System.setProperty("foo", "baz");
	}

	@Order(2)
	@Test
	void test2() {
		assertThat(System.getProperty("foo")).isEqualTo("baz");
	}

}

Thoughts?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Out-of-order execution · Issue #9566 · jupyterlab ... - GitHub
Description Manually executing cells while the kernel is restarting leads to out-of-order cell execution: Reproduce Open this binder: ...
Read more >
What's new in Kotlin 1.7.0
Changes in compile tasks. New statistics of generated files by each annotation processor in kapt. Deprecation of the kotlin.compiler.execution.
Read more >
How to solve "Plugin execution not covered by lifecycle ...
Window > Preferences > Maven > Errors/Warnings > Plugin execution not covered by life-cycle configuration.
Read more >
November 2022 (version 1.74) - Visual Studio Code
Changes that are equal on both sides are now automatically resolved. Extensions that provide git blame functionality now work in the incoming, current, ......
Read more >
Building applications with Maven - Quarkus
The Quarkus Maven plugin includes a goal called info (currently marked as 'experimental') that logs Quarkus-specific information about the project, such as: the ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found