Skip to content
This repository has been archived by the owner on Dec 7, 2024. It is now read-only.

Unit testing, and visibility of the 'setpointCommand' methods #26

Open
viggy96 opened this issue Sep 21, 2022 · 0 comments
Open

Unit testing, and visibility of the 'setpointCommand' methods #26

viggy96 opened this issue Sep 21, 2022 · 0 comments

Comments

@viggy96
Copy link

viggy96 commented Sep 21, 2022

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.

@viggy96 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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant