-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Return subcommand execution result in ConsoleLauncher
#3322
Return subcommand execution result in ConsoleLauncher
#3322
Conversation
29b6ddd
to
7a0a854
Compare
When explicitly specifying the `execute` subcommand as advised by: > WARNING: Delegated to the 'execute' command. > This behaviour has been deprecated and will be removed in a future release. > Please use the 'execute' command directly. ... it happens that `ConsoleLauncher.run` returns a `CommandResult` whose `getValue` method always returns `Optional.empty()` instead of the expected (non-empty) `Optional<TestExecutionSummary>`. It turns out that, when `picocli` executes a _subcommand_, it doesn't propagate the return value to the parent `CommandLine`, whose `getExecutionResult` method then returns `null`. There was a question about it last year (remkop/picocli#1656) answered by the [user manual](https://picocli.info/#_executing_commands_with_subcommands): > The `ParseResult` can be used to get the return value from a Callable > or Method subcommand: > ```java > // getting return value from Callable or Method command > Object topResult = cmd.getExecutionResult(); > > // getting return value from Callable or Method subcommand > ParseResult parseResult = cmd.getParseResult(); > if (parseResult.subcommand() != null) { > CommandLine sub = parseResult.subcommand().commandSpec().commandLine(); > Object subResult = sub.getExecutionResult(); > } > ``` The present change therefore consists in implementing it. Note: prior to the change, presently adapted tests (now parameterized so as to cover both forms) were all failing on: ```java java.lang.IllegalStateException: TestExecutionSummary not assigned. Exit code is: 0 at app//org.junit.platform.console.ConsoleLauncherWrapperResult.checkTestExecutionSummaryState(ConsoleLauncherWrapperResult.java:42) at app//org.junit.platform.console.ConsoleLauncherWrapperResult.getTestsFoundCount(ConsoleLauncherWrapperResult.java:102) ```
7a0a854
to
e3b0824
Compare
@ParameterizedTest | ||
@ValueSource(strings = { "-e junit-jupiter -p org.junit.platform.console.subpackage", | ||
"execute -e junit-jupiter -p org.junit.platform.console.subpackage" }) | ||
void executeWithoutExcludeClassnameOptionDoesNotExcludeClassesAndMustIncludeAllClassesMatchingTheStandardClassnamePattern( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good candidate for longest method name in this project. ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to rotate my screen to read it in full ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good candidate for longest method name in this project. ;-)
Mmmm.... looks like I'm getting some competition! 😈
null
)
Danke, Marc! |
ConsoleLauncher
@rdesgroppes Thank you! 🙂 |
Overview
When explicitly specifying the
execute
subcommand as advised by:... it happens that
ConsoleLauncher.run
returns aCommandResult
whosegetValue
method always returnsOptional.empty()
instead of the expected (non-empty)Optional<TestExecutionSummary>
.It turns out that, when
picocli
executes a subcommand, it doesn't propagate the return value to the parentCommandLine
, whosegetExecutionResult
method then returnsnull
.There was a question about it last year (remkop/picocli#1656) answered by the user manual:
The present change therefore consists in implementing it.
Note: prior to the change, presently adapted tests (now parameterized so as to cover both forms) were all failing on:
I hereby agree to the terms of the JUnit Contributor License Agreement.
Definition of Done
[ ] Method preconditions are checked and documented in the method's Javadoc[ ] Public API has Javadoc and@API
annotations[ ] Change is documented in the User Guide and Release Notes