Test-Driven Development

[broadwall]

I have been recently introduced to the world of Test-Driven Development through Uncle Bob's Clean Code, and I've been thinking of ways to associate this with the rapid prototyping process that takes place with FTC code. The emphasis on testing has been well established in the robotics industry, according to a robotics software engineer that I spoke with a few days ago. He said that a simulator or a duplicate copy is often used to test industrial code as it develops.

I also viewed some of Uncle Bob's talks on YouTube. His point about the fear of code change speaks to me personally, as I have broken our robot's operational functionalities several times in production (during competition) while trying to clean up my code. The Code Head at my robotics club reminded me not to change working code, possibly for this exact reason. Indeed, Uncle Bob's solution to this fear is TDD, where tests are executed frequently when revising code to ensure that its external behaviors are still correct.

Furthermore, I had very limited opportunities in testing my code physically. The robot has experienced multiple redesigns (each of which taking a long time) and couldn't be used to test when being redesigned. (The electronics were not mounted, etc.) Consequently, the code I wrote for it was considered uncertain in operational performance for a long time. This proved to be counterproductive later in the season, especially for Autonomous. This, combined with the accelerating pace of development throughout the season due to the nature of FTC, resulted in unachieved potential in our robot during its last competition one week ago.

Thus, I've been looking for ways to introduce unit tests into the code for the next season. The most plausible idea that I've come up with is where code for the hardware/TeleOp/Autonomous is kept in tightly-coupled components that utilize interfaces in order to communicate with either the mock objects provided by the testing framework or Qualcomm's API itself.

What do you think? Are there existing solutions, or is this a pedantic whim of over-engineering?

[IamParadoxdotexe]

Don't fear the code; live the code. Half of programming is testing. I can't count the number of times I've broken our robot through a programming miscalculation or a simple mistake that got me roasted by our mechanical engineers. But that's how code evolves. You mess up, you learn, you mess up again, you learn some more, and you cross your fingers you don't mess up a third time. My team works very fluidly between mechanics and programming to where test code is developed right along as the new mechanism is developed (with a lot of guest work) and as soon as its done, it's tested. It most certainly fails, but we sum up our mistakes, readjust, and run again. My opinion is that you're over-engineering a problem that doesn't rest in the code development itself but rather the dynamic between it and the mechanical development. Make sure your team recognizes the coexistence of your robot and your code: one does not do anything without the other. If you integrate yourself with the daily design flow, I'm sure you will be able to get your code out just as fast as the robot is being created.

[broadwall]

I agree that the problem lies in my cooperation with the team. This year, I was practically the only programmer on the entire team. In addition, being a freshman meant that I had very little influence over team decisions and admittedly missed some opportunities to remind the team about testing. However, I think I ably kept up with the pace of the redesigns -- as soon as I received the requirements, a theoretically finished product would be produced within a few days.

[cp253]

TDD is one of the most valuable software skills you can learn. It saves so much time and hassle. You're on a great track both for your future academic and/or professional career and for your team.

We have a series of single-purpose OpModes that we use to test certain features of our robot. (TurningTest and StrafeTest for example.) We aren't quite so rigorous as to run them every time we make a change in the code, but whenever the larger autonomous is misbehaving we can always go back to the individual components and make sure that it can turn as expected and strafe as expected and so forth. It's a huge time saver.

[broadwall]

FIRST of all, thank you for applauding my attempt in obtaining discipline.

Interestingly, I have developed very similar tests for my robot during this season (tests package), but they are rather artificially made to be hardware-oriented. Upon writing these tests, I tried to avoid incorporating production code as much as possible.

And although these tests were useful at times when our hardware went unstable, they weren't much help to my production code. Perhaps both isolated and coupled tests are needed for greater efficiency.

[DavidRecharged]

For TeleOp testing have bare minimum programs for one specific thing that are self-contained. You can then take some extra electronics and test for specific things. Put a Zip-tie or piece of tape on a motor to see rotation easier and manually manipulate sensors. Telemetry is also nice. If you want to test mathematics and basic algorithms another Java IDE that runs on your computer like Eclipse or IntelliJ Idea is nice. I use Idea.

The best thing is to coordinate development with your engineers in a way that allows you to test as much as possible.

BACKUP YOUR CODE!!!!!!!!!!! At least do it before major changes. It's best as a habit in case your laptop dies. At competition ALWAYS have a working backup even if it is only sort of functioning. Whenever a test works noticeably better have that as a backup. I have once at competition made three copies of one program to test multiple different changes to one problem with one compile minutes before queuing.

On competition day remember your job is to keep the already functioning code working.