Skip to content
MARSLib Documentation

Intro to CI/CD & Testing

If you’re new to software engineering, you might think the only way to know if your code works is to put the robot on a carpet, cross your fingers, and hit “Enable”. In reality, the professional software industry—and MARSLib—uses CI/CD as a basic exercise in Teamwork. These automated systems act as a 24/7 technical mentor, ensuring our collective Innovation is safe, robust, and ready to have a championship-grade Impact before we ever touch the physical machine.

What is CI/CD?

Section titled “What is CI/CD?”

Continuous Integration (CI) is the practice of automatically testing and verifying every piece of code you write the moment you attempt to save or share it with the team.

Instead of manually checking for misspelled variables, messy brackets, or logic flaws, the CI Pipeline is a robotic supervisor living in GitHub. Every time you push a file, the CI pipeline boots up an isolated computer in the cloud and runs a strict checklist on your work. Only if everything passes perfectly will your code be officially integrated into MARSLib.

Why is CI Important for FRC?

Section titled “Why is CI Important for FRC?”

  • Robot Safety: If you accidentally type 1.0 instead of 0.1 for motor speed, the CI simulator will detect an unsafe launch trajectory before the real robot launches a ball into the ceiling.

  • Zero Memory Leaks: The CI ensures no “garbage memory” allocations occur, meaning our 20ms physics loops never lag during a World Championship match.

  • Readability: A developer working at 3 AM might forget to indent their code cleanly. CI automatically reformats it so the whole team can read it easily the next day.

How MARSLib Implements CI

Section titled “How MARSLib Implements CI”

When you run ./gradlew build locally, or push to GitHub, you trigger our rigorous pipeline. This is what it checks:

1 Spotless Formatting

Section titled “1 Spotless Formatting”

Spotless is our automated grammar checker. It forces everything (brackets, spacing, import lines) into the strict Google Java format. If your code is messy, you can run ./gradlew spotlessApply to have it instantly fixed.

2 PMD Static Analysis

Section titled “2 PMD Static Analysis”

PMD is a tool that reads your raw code looking for code smells. Did you create an array but never use it? Did you leave a variable open that causes a memory leak? PMD catches it and instantly fails your build until you fix it.

3 Dyn4j Physics Testing

Section titled “3 Dyn4j Physics Testing”

The crown jewel of our pipeline is deterministic physics testing. We have over 89 automated tests (JUnit 5) that run against Dyn4j—a 2D collision engine. Rather than “mocking” or pretending the code worked, these CI tests actually spawn virtual swerve modules, drop a virtual ball, and run your Autonomous route to ensure physics limits (like motor stall torque) aren’t violated.

4 Test Coverage (JaCoCo)

Section titled “4 Test Coverage (JaCoCo)”

Writing tests is only half the battle; knowing what we tested is equally critical. Our pipeline uses JaCoCo (Java Code Coverage) to generate reports every time tests run.

When a Pull Request is submitted, the CI pipeline fails if the new code introduces a drop in overall test coverage. This enforces a strict standard: any new state machine, math utility, or algorithm must have an accompanying JUnit test proving it works safely under physical simulation before it is merged into the championship codebase.

📖 Further Reading & External Resources

Section titled “📖 Further Reading & External Resources”