-
Notifications
You must be signed in to change notification settings - Fork 611
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
[commands] Use factories and decorators in Command tests #7006
[commands] Use factories and decorators in Command tests #7006
Conversation
command1 and command2 are mock Commands that don't actually implement Command decorators
This PR modifies commands. Please open a corresponding PR in Python Commands and include a link to this PR. |
/format |
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.
Looks good to me but needs C++ and Python ports
/format |
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'm a bit iffy about using factories instead of the command constructors in tests that are specifically testing those command types, but the command constructors also don't support CommandPtr
. I could see either way (replacing command constructors in command type tests with factories or not using any factories in command type tests) being fine. @rzblue thoughts?
wpilibNewCommands/src/test/native/cpp/frc2/command/DefaultCommandTest.cpp
Outdated
Show resolved
Hide resolved
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.
Submitted before I meant to, whoops. I've also updated my comment with a list of what needs to be changed.
wpilibNewCommands/src/test/native/cpp/frc2/command/SequentialCommandGroupTest.cpp
Outdated
Show resolved
Hide resolved
|
/format |
Great progress! I've updated the list of changes to make.
For P.S. I get email notifications for GitHub comments on this PR (and other PRs I've participated in), and I also usually see all updated PRs (which includes PRs with new commits) within a day. If you want to make sure I see it, though, you can always keep on requesting my review- Emails are cheap! |
For |
Ah, you're right, I missed that. Don't worry about them, then. |
|
Ah, I missed that too. I think that leaves just |
I think everything on the checklist is done now. |
Whoops, looks like I missed these earlier:
Other than that, should be everything. (Though I am still iffy about using the factories in tests of the command classes themselves) |
I feel like it should be fine? The actual code logic is entirely identical so the only way for the factories to break is for the command behind the factory to break, which preserves the function of the command unit tests. |
Done those 2. |
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.
Looks good to me, for what it's worth. One of the actual maintainers will need to review and approve this too before this gets merged.
@@ -45,7 +45,7 @@ void requirementUninterruptibleTest() { | |||
Subsystem requirement = new SubsystemBase() {}; | |||
|
|||
Command notInterrupted = | |||
new RunCommand(() -> {}, requirement) | |||
Commands.idle(requirement) |
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.
Does requirement.idle()
exist?
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.
No
Closes #6652.