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.
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.