[jira] [Comment Edited] (SLING-10396) JUnit Teleporter should (also) be available as Jupiter Extension

["Julian Sedding (Jira)" <ji...@apache.org>]

    [ 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)