Class Tests

[ThadHouse]

We need to test all of the classes we have implemented. I will try and do as much as I can with only a RoboRIO, but we will need help for sure on this from real robots. I will add all of our classes to this at some point. What we want to do is cross out all the ones that have been tested and work successfully. If a class fails, create a new issue, and put a link to that issue next to the class.

[ThadHouse]

Buttons

• Button
• ButtonSchedulers
• InternalButton
• JoystickButton
• NetworkButton
• Trigger

[ThadHouse]

Commands

• Command
• CommandGroup
• PIDCommand
• PIDSubsystem
• PrintCommand
• Scheduler
• StartCommand
• Subsystem
• WaitCommand
• WaitForChildren
• WaitUntilCommand

[ThadHouse]

LiveWindow

• LiveWindow
• LiveWindowSendable

SmartDashboard

• SendableChooser
• SmartDashboard

[ThadHouse]

ADXL345_I2C ADXL345_SPI AnalogAccelerometer AnalogInput AnalogOutput AnalogPotentiometer AnalogTrigger BuiltInAccelerometer CANJaguar CANTalon Compressor Controller ControllerPower Counter DigitalInput DigitalOutput DigitalSource DoubleSolenoid DriverStation Encoder GearTooth Gyro I2C - Tested using ADXL345_I2C InterruptableSensorBase Jaguar Joystick MotorSafety Notifier PIDController PowerDistributionPanel Preferences Relay RobotDrive SPI - using ADXL345_SPI SerialPort Servo Solenoid Talon TalonSRX Timer Ultrasonic Victor VictorSP

[jkoritzinsky]

A lot (if not all) of these classes can be tested with unit tests. Since many of them are actually little more than wrappers over the HAL, they would just require a mock HAL built for testing, which is actually pretty easy to do with its current architecture. The rest can be tested normally with unit tests.

Additionally, the nice thing about unit tests is that we can test after we make changes and ensure that we don't break anything. This allows us to make sure we don't accidentally create bugs and also optimize some internals without worrying about breaking the code.

[ThadHouse]

I know that the python implementation uses the sim to test. We could and should do that, but in inital test on real hardware would be nice. Like for some reason I was trying to test I2C the other day, and it wasnt working. However I built a small sim test and it did. So sometimes the software doesnt always match the hardware.

[jkoritzinsky]

I agree that we should do hardware tests, but we should have an automated test suite for the code, especially considering that we won't always have access to the hardware while making changes.

[ThadHouse]

These are all basically done. There are a few more, mostly involving CAN, but otherwise pretty much everything else has unit tests and/or integration tests. In addition, All motor controllers, CAN functionality (CAN Talon, PCM, and PDP), AIO, DIO have been tested on a physical roborio and are known to work. The only things that have not been tested are I2C and SPI, which I will work on soon, and create their own issues.