Add Unit Testing article

[Starlight220]

Split from #1077

I'll add some cleanup input I got from @ThadHouse, and I'd like help with the C++ parts.

[Daltz333]

Additionally, can you copy and paste this class and verify that all the code runs as expected? I found a if/else syntax error and could miss other things.

[jasondaming]

I think this sentence sounds awkward: "There are many unit testing frameworks for most languages". "Unit testing is very common and most languages have multiple frameworks" or similar would be my suggestion.

I think it is important to mention under "Writing Testable Code" that they can't define their hardware inline if they want to use unit tests. E.g. private final WPI_TalonSRX m_talonsrxleft = new WPI_TalonSRX(DriveConstants.kLeftMotor2Port);

I think it would be also good to mention / show how a project needs to use methods to break apart their code so that individual sections can be tested. I am just trying to keep the "I am doing everything in "main" user in mind."

What do you think about mentioning Mockito? I (and I know others) have been using it (admittedly not as much as I would like) and I think it makes things significantly easier.

[Starlight220]

I agree about the splitting into methods part, though I'm not sure how critical it is an FRC context as each subsystem action is pretty obviously a separate method.

What do you mean about inline hardware definitions?

I'm not sure how Mockito comes into play here, but I've never used it.

[jasondaming]

So I guess what I am saying is that your code looks great but for teams that aren't set up with subsystems (lowercase) providing and example might help. I will make a quick example.

Many teams do:

if (m_controller.getYButtonPressed()) {
   if (spark.get() >= .75) {
      spark.set(0.75);
   }
   else {
      spark.set(0);
   }
}

To use unit testing it will need to be:

if (m_controller.getYButtonPressed()) {
   toggleIntakeMotor();
}

public void toggleIntakeMotor() {
   if (spark.get() >= .75) {
      spark.set(0);
   }
   else {
      spark.set(0.75);
   }
}

Mockito allows you to mock() your hardware and not have to worry about the closing stuff. Amongst a lot of other things. Here is a good video on using Mockito in FRC that we could include.

[Starlight220]

Template robot projects don't have Mockito, that's already a big reason against documenting its usage in an FRC context. If it doesn't have a C++ equivalent, then it definitely won't be documented/suggested.
Specifically about that video - it's terribly outdated and from before all the sim stuff was added. Part of the reason that all the XxxSim classes exist is to make mocking hardware unnecessary and provide a better, more appropriate alternative.

Regarding your example, there are classes to simulate joystick input (see GenericHIDSim and the like). The current example shows the most basic case, given that it's more a tutorial than an example. Adding an integration test example/tutorial (perhaps similar to https://github.com/wpilibsuite/allwpilib/blob/main/wpilibj/src/test/java/edu/wpi/first/wpilibj/TimedRobotTest.java) that tests buttons or whatever can also be done but should be a later separate PR.

[Starlight220]

given wpilibsuite/GradleRIO#497, it would seem that Gradle never runs tests on deploy. The VS Code option might though.

I don't have access to a robot, can someone check this?

[jasondaming]

I think there should be a warning about the lack of support from 3rd party vendors about .close and any other things lacking implementation.

I had a lot of trouble with import static org.junit.Assert.*; "The import org.junit.Assert cannot be resolved"

[Starlight220]

@Daltz333 is there anything else you'd like me to add, or can this be reviewed/merged?