uncaught exceptions in junit5 tests about osgi-test

[rotty3000]

that last exception is odd:

10226 [ool-16-thread-1] ERROR o.j.j.e.e.JupiterEngineExecutionContext:148 - Caught exception while closing extension context: org.junit.jupiter.engine.descriptor.MethodExtensionContext@20bb6a97
org.osgi.framework.InvalidSyntaxException: Filter ended abruptly: (&(objectClass=org.osgi.test.junit5.types.Foo)(foo=baz)
	at org.eclipse.osgi.internal.framework.FilterImpl$Parser.parse(FilterImpl.java:1378)
	at org.eclipse.osgi.internal.framework.FilterImpl.newInstance(FilterImpl.java:180)
	at org.eclipse.osgi.internal.framework.FilterImpl.newInstance(FilterImpl.java:176)
	at org.osgi.framework.FrameworkUtil.createFilter(FrameworkUtil.java:72)
	at org.osgi.test.common.exceptions.FunctionWithException.lambda$orElseThrow$0(FunctionWithException.java:21)
	at org.osgi.test.common.filter.Filters.format(Filters.java:43)
	at org.osgi.test.common.service.ServiceConfiguration.<init>(ServiceConfiguration.java:53)
	at org.osgi.test.junit5.service.ServiceExtension.lambda$getServiceUseConfiguration$1(ServiceExtension.java:146)
	at org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$getOrComputeIfAbsent$0(ExtensionValuesStore.java:81)
	at org.junit.jupiter.engine.execution.ExtensionValuesStore$MemoizingSupplier.get(ExtensionValuesStore.java:182)
	at org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:58)
	at org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:73)

Shouldn't the memoize have been initialized? Wouldn't not having been initialized indicate that it shouldn't be created just to be destroyed?

[rotty3000]

Specifically, the scenario for that test was that initial configuration was bad. Shouldn't that be reflected somehow in the teardown?

[rotty3000]

thirdly, I'm not sure if it's only me, but in the cli these exceptions do not result in failures. I get:

Test run finished after 10004 ms
[        58 containers found      ]
[         0 containers skipped    ]
[        58 containers started    ]
[         0 containers aborted    ]
[        58 containers successful ]
[         0 containers failed     ]
[       137 tests found           ]
[         0 tests skipped         ]
[       137 tests started         ]
[         0 tests aborted         ]
[       137 tests successful      ]
[         0 tests failed          ]

However, in Eclipse I get:

[kriegfrj]

@bjhargrave: Executive Summary is that those stack traces are expected.

Detail: Note that they all start off like this:

2020-06-11T17:23:53.1309781Z 	at org.junit.platform.testkit.engine.EngineTestKit.execute(EngineTestKit.java:189)
2020-06-11T17:23:53.1316787Z 	at org.junit.platform.testkit.engine.EngineTestKit.access$100(EngineTestKit.java:54)
2020-06-11T17:23:53.1325837Z 	at org.junit.platform.testkit.engine.EngineTestKit$Builder.execute(EngineTestKit.java:343)
2020-06-11T17:23:53.1335766Z 	at org.osgi.test.junit5.service.AbstractServiceExtensionTest.assertThatTest(AbstractServiceExtensionTest.java:126)
2020-06-11T17:23:53.1347349Z 	at org.osgi.test.junit5.service.AbstractServiceExtensionTest.lambda$futureAssertThatTest$0(AbstractServiceExtensionTest.java:113)
2020-06-11T17:23:53.1353191Z 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
2020-06-11T17:23:53.1362322Z 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
2020-06-11T17:23:53.1372502Z 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
2020-06-11T17:23:53.1380238Z 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
2020-06-11T17:23:53.1387473Z 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

They are generated by these tests:

osgi-test/org.osgi.test.junit5/src/test/java/org/osgi/test/junit5/service/ServiceExtensionTest.java

Lines 195 to 201 in 272d362

	@Test
	public void malformedFilter() throws Exception {
	futureAssertThatTest(ServiceWithMalformedFilter.class).isInstanceOf(
	InvalidSyntaxException.class)
	.hasMessageContaining(MALFORMED_FILTER);
	assertThat(TestBase.lastService.get()).isNull();
	}

osgi-test/org.osgi.test.junit5/src/test/java/org/osgi/test/junit5/service/ServiceExtensionTest.java

Lines 213 to 214 in 272d362

	@Test
	public void negativeCardinality() throws Exception {

osgi-test/org.osgi.test.junit5/src/test/java/org/osgi/test/junit5/service/ServiceExtensionTest.java

Lines 230 to 231 in 272d362

	@Test
	public void negativeTimeout() throws Exception {

Each of these tests have the following structure:

1. Start with a dummy test class with a misconfigured @InjectService annotation.
2. Run the test class in Jupiter using EngineTestKit (scheduled to run in the executor).
3. Assert that the result throws the expected exception.

So the logging that you are seeing is generated by the nested JupiterTestEngine instance, which is running the dodgy test classes and so is expected to generate those exceptions.

We need to pass in the right parameters to JupiterTestEngine in the EngineTestKit run to suppress the logging to the console.

[kriegfrj]

that last exception is odd:

Shouldn't the memoize have been initialized? Wouldn't not having been initialized indicate that it shouldn't be created just to be destroyed?

Specifically, the scenario for that test was that initial configuration was bad. Shouldn't that be reflected somehow in the teardown?

Forgive me @rotty3000 , I'm not sure that I follow here? Does my response to @bjhargrave shed any light on this for you? If not, I'm not quite sure that I've understood your point (or more precisely, I should say that I'm quite sure I have not understood your point 😄). One thing that I am fairly sure about though is that this issue is probably different to the one that prompted @bjhargrave to raise this issue.

[kriegfrj]

thirdly, I'm not sure if it's only me, but in the cli these exceptions do not result in failures. I get:

As the exceptions are expected behaviour, they should not result in failures in the CLI or in Eclipse.

The Eclipse test that is failing in your screenshot is a legitimate problem, but seems completely unrelated to the OP (which was a problem with the tests for ServiceExtension, while yours in the screenshot was a problem with tests for BundleContextExtension). I have not seen that behaviour before - if you see it again, next time can you cut-and-past the failure stack trace(s) for the failing test(s) and I'll try and investigate.

[rotty3000]

it's fine, there is nothing overly important in my comments, just adding observations. Feel free to ignore them.