You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 7, 2024. It is now read-only.
My team uses the Mockito framework to perform unit testing on our code. This is very simple to do with CTRE products as I can simply mock the motor controller object itself, and track what method calls the object attempts to make. However, with Spark Max motor controllers, this is unnecessarily difficult through the use of separate objects for PID control, limit switches etc. Meaning I have to be able to mock out other abstract objects just to be able to unit test the team's code.
I recently noticed that REV has a convenient setpointCommand method available, however these methods are not visible to the user.
If these methods were made public things would be much easier to use, and the API would be very similar to the CTRE, where you can simply use the set method and specify the mode.
The use of separate objects for the PID controller and limit switches makes the API much more clunky to use IMO. Especially when in the background, the PID controller is just calling the regular Spark Max object anyway and using the setpointCommand method.
I would highly recommend that REV rethink its API architecture. At the very least, expose the setpointCommand methods for users to use if they wish.
The text was updated successfully, but these errors were encountered:
viggy96
changed the title
Unit testing, and deprecation of the 'setpointCommand' methods
Unit testing, and visibility of the 'setpointCommand' methods
Sep 21, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
My team uses the Mockito framework to perform unit testing on our code. This is very simple to do with CTRE products as I can simply mock the motor controller object itself, and track what method calls the object attempts to make. However, with Spark Max motor controllers, this is unnecessarily difficult through the use of separate objects for PID control, limit switches etc. Meaning I have to be able to mock out other abstract objects just to be able to unit test the team's code.
I recently noticed that REV has a convenient
setpointCommand
method available, however these methods are not visible to the user.If these methods were made public things would be much easier to use, and the API would be very similar to the CTRE, where you can simply use the
set
method and specify the mode.The use of separate objects for the PID controller and limit switches makes the API much more clunky to use IMO. Especially when in the background, the PID controller is just calling the regular Spark Max object anyway and using the
setpointCommand
method.I would highly recommend that REV rethink its API architecture. At the very least, expose the
setpointCommand
methods for users to use if they wish.The text was updated successfully, but these errors were encountered: