-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Premise
Based on the current documentation, it is expected that MessageOutput redirects all command logs when passed to BetterCommandRunner:
-
A proxy for user-provided functions for passing specific log messages.
-
[...] adds additional functionality such as logging, [...]
Problem
For any program mock based on BetterCommandRunner with a custom MessageOutput, run:
mock help helpor
mock help -hIt is a valid command, as it seeks usage information about the help command of the mock program. The command log in this case, unfortunately, does not pass through MessageOutput.
Cause
As per my assessment, I believe this problem is caused by the following design:
-
MessageOutputis injected through onlyBetterCommand -
BetterCommandis a child of upstreamCommand -
The private
HelpCommandis a child ofCommandbut notBetterCommand -
BetterCommandRunnerindirectly addsHelpCommandvia itssuper-call
Essentially, in this inheritance schema, BetterCommand is a sibling of HelpCommand and not a parent. It fails to meet the goal of printUsage.
Suggestion
I reckon this design bug could be patched by passing the buck to the upstream package for their private implementation of HelpCommand, or, by making their CommandRunner an even better BetterCommandRunner by choosing implements over extends such that it not only satisfies all design contracts but also provides the ability to customize the constructor to add a proper HelpCommand that inherits from BetterCommand.
Aside, there is another limitation with both BetterCommandRunner and the upstream CommandRunner constructor that it fails to allow the customization of its argParser similar to an issue mentioned earlier.
Hopefully, all such issues can be fixed without relying on upstream support through this approach.