Skip to content
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

Updated unit tests #1709

Closed
wants to merge 4 commits into from
Closed

Updated unit tests #1709

wants to merge 4 commits into from

Conversation

MikeTheSnowman
Copy link
Contributor

@MikeTheSnowman MikeTheSnowman commented Jun 15, 2022

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:
image

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
Copy link
Contributor Author

Sorry, pull request sent to the wrong repo.

@remkop
Copy link
Owner

remkop commented Jun 15, 2022

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

@MikeTheSnowman
Copy link
Contributor Author

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
Copy link
Owner

remkop commented Jun 15, 2022

@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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants