[
https://issues.apache.org/jira/browse/SLING-10396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364315#comment-17364315
]
Julian Sedding edited comment on SLING-10396 at 6/16/21, 1:58 PM:
------------------------------------------------------------------
I am abandoning this issue, because I really only need access to OSGi services
but I don't have the need for remote test execution. Furthermore, the existing
{{TeleporterRule}} is tied in multiple ways to JUnit 4:
- most obviously: the primary API, i.e. the {{TeleporterRule}}, implements
JUnit 4's {{TestRule}}
- test results are transmitted between server and client as serialized (JUnit
4) {{Result}} objects
- Sling JUnit's {{Renderer}} API uses JUnit 4's {{RunListener}}, which means it
is easy to get access to JUnit 4 objects within a {{Renderer}}, but not to get
access to Jupiter objects
All of the above would require serious refactoring and rewriting. Particularly
if backwards compatibility and code-reuse between the JUnit 4 and Jupiter
implementations is desired.
In case someone wants to pick this up in the future, here are some hints on how
a teleporter mechanism could be implemented as a Jupiter {{Extension}}: the
most suitable way to implement a {{TeleporterExtension}} seems to be an
{{InvocationInterceptor}}, specifically the method
[{{InvocationInterceptor#interceptTestMethod}}|https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/InvocationInterceptor.html#interceptTestMethod(org.junit.jupiter.api.extension.InvocationInterceptor.Invocation,org.junit.jupiter.api.extension.ReflectiveInvocationContext,org.junit.jupiter.api.extension.ExtensionContext)].
Within this method, if {{Invocation#skip()}} is called, the actual (i.e. local
or client-side) test method is not executed. Instead an implementation would
here call the server-side execution and expect back a result containing (at
least) the serialized {{Exceptions}} of test failures. The exception would be
deserialized and re-thrown. For the happy case, i.e. when a test passes, no
further action should be required. On the server-side, a call to
{{Invocation#proceed()}} would trigger the normal execution of the test method.
Seamless integration of code-coverage computation might be an additional
challenge. I have not investigated this aspect.
was (Author: jsedding):
I am abandoning this issue, because I really only need access to OSGi services
but I don't have the need for remote test execution. Furthermore, the existing
{{TeleporterRule}} is tied in multiple ways to JUnit 4:
- most obviously: the primary API, i.e. the {{TeleporterRule}}, implements
JUnit 4's {{TestRule}}
- test results are transmitted between server and client as serialized (JUnit
4) {{Result}} objects
- Sling JUnit's {{Renderer}} API uses JUnit 4's {{RunListener}}, which means it
is easy to get access to JUnit 4 objects within a {{Renderer}}, but not to get
access to Jupiter objects
All of the above would require serious refactoring and rewriting. Particularly
if backwards compatibility and code-reuse between the JUnit 4 and Jupiter
implementations is desired.
In case someone wants to pick this up in the future, here are some hints on how
a teleporter mechanism could be implemented as a Jupiter {{Extension}}: the
most suitable way to implement a {{TeleporterExtension}} seems to be an
{{InvocationInterceptor}}, specifically the method
[{{InvocationInterceptor#interceptTestMethod}}|https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/InvocationInterceptor.html#interceptTestMethod(org.junit.jupiter.api.extension.InvocationInterceptor.Invocation,org.junit.jupiter.api.extension.ReflectiveInvocationContext,org.junit.jupiter.api.extension.ExtensionContext)].
Within this method, if {{Invocation#skip()}} is called, the actual (i.e. local
or client-side) test method is not executed. Instead an implementation would
here call the server-side execution and expect back a result containing (at
least) the serialized {{Exception}}s of test failures. The exception would be
deserialized and re-thrown. For the happy case, i.e. when a test passes, no
further action should be required. On the server-side, a call to
{{Invocation#proceed()}} would trigger the normal execution of the test method.
Seamless integration of code-coverage computation might be an additional
challenge. I have not investigated this aspect.
> JUnit Teleporter should (also) be available as Jupiter Extension
> ----------------------------------------------------------------
>
> Key: SLING-10396
> URL: https://issues.apache.org/jira/browse/SLING-10396
> Project: Sling
> Issue Type: Improvement
> Components: JUnit Core, Testing
> Affects Versions: JUnit Tests Teleporter 1.0.22, JUnit Core 1.1.2
> Reporter: Julian Sedding
> Assignee: Julian Sedding
> Priority: Minor
>
> The {{TeleporterRule}} is specific to JUnit 4. It would be great to also make
> it available as a JUnit Jupiter (aka JUnit 5) Extension.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
