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 a system called CI/CD to guarantee our code is safe before we ever touch the physical machine.

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?

  • 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

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

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

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

The crown jewel of our pipeline is deterministic physics testing. We have over 89 automated tests (JUnit) 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.



📖 Further Reading & External Resources