Updated unit tests

[MikeTheSnowman]

Hey @rsenden,
Here's a summary of changes for the i18n unit test case for your update to resolve issue #1706 .

The primary change what was made:

• Added new class with option to act ac a Mixin option between parent command and subcommand
• Added description for the new option in SharedMessages resource bundle
• Created new subcommand class called sub2 and added the previously mentioned option as a Mixin. Also, sub2 has been to use a different resource bundle than the parent command.
• Added the new sub2 command and new Mixin option to the parent command

Other changes that were made so that other existing i18n tests don't break:

• Updated the japanese resource (SharedMessages_ja) with description for the new mixin option
• Added the method stripFactoryInstanceHashcodes to TestUtil to strip to remove hash codes (object instance IDs?) from trace output so that testTracingWithResourceBundle will not fail due to my updates to the test command.
• Updated the expect string variables for many of the other test cases.

One area of concern:

During testing, if there's a parent command that uses a resource bundle where the "usage.header" key is defined, but a subcommand's resource bundle doesn't (and also doesn't have a usage header or description defined in the subcommand's @command annotation) then the subcommand will adopt the "usage.header" key from the parent resource bundle to be used as the subcommand's description when the parent command's help output is displayed. Please see image below:

Please let me know if this is expected behavior or if we should instead be expecting to see a blank/emty description of that subcommand from the parent command's help message output. If this is not intended, then for this scenario, I'll update the existing tests to fail if they see anythin for the subcommand's help message output.

[MikeTheSnowman]

Sorry, pull request sent to the wrong repo.

[remkop]

For what it’s worth, the behaviour described in the area of concern sounds reasonable to me.

[MikeTheSnowman]

For what it’s worth, the behaviour described in the area of concern sounds reasonable to me.

Hey @remkop. Do you think I should raise this as a new issue?

[remkop]

@wtfacoconut Sorry I was unclear; I meant that the behaviour you describe sounds fine:
if a subcommand does not have an entry in its resource bundle then this subcommand showing the entry from the parent command resource bundle sounds exactly right. (So I don't think we need a new ticket, unless I am missing something.)

If you can work with @rsenden on this that would be great.
I won't be able to review any pull requests until after this weekend.
Many thanks for contributing to this!

[MikeTheSnowman]

No worries and thank you for the clarification. Yes, I'll tag team with rsenden. 👍