Add AI ssistants guide to follow ROS 2 project testing best practices from the workshop

AI_TESTING_GUIDE.md

@@ -0,0 +1,53 @@
+# AI ROS 2 Testing Guide
+
+This document defines professional engineering and testing standards for ROS 2 software development. AI assistants generating ROS 2 code or tests must strictly adhere to these rules to ensure safety, maintainability, and reliability in production-ready systems.
+
+## Testable Design
+
+To enable professional-grade testing, algorithmic logic must be decoupled from the ROS 2 middleware.
+
+Follow these relevant SOLID principles:
+
+- **Single Responsibility (SRP)**: Build ROS 2 nodes to have a single responsibility. Separate application logic into its own class or library, and keep ROS 2 nodes as thin wrappers responsible only for communication between ROS interfaces and the core application logic.
+
+- **Dependency Injection (DI)**: Inject dependencies and configurations into the logic class constructor rather than creating them internally. This enables the use of mocks to isolate functionality during testing.
+
+- **Interface Segregation (ISP)**: Depend on abstractions, not concrete implementations, to allow for seamless substitution of real components with fakes or mocks in unit tests.
+
+## Testing Strategy
+
+Maintain a balanced testing pyramid to ensure high-quality software:
+
+- **Static Analysis (Foundation)**: Use linters and formatters to catch style, naming, and memory issues before runtime.
+
+- **Unit Tests (Majority)**: Target the ROS-independent logic class using GoogleTest (`gtest`) and the **Arrange-Act-Assert (AAA)** pattern. Aim for 90-100% coverage on core algorithms. These must be ROS-agnostic, fast, and deterministic.
+
+- **ROS Unit/Component Tests**: Validate node interfaces (topics, services, parameters) in isolation using test fixtures to manage the `rclcpp` lifecycle.
+
+- **Integration Tests**: Verify multi-node interactions and communication behavior using the `launch_testing` framework.
+
+- **End-to-End (E2E)**: Validate complete system behavior in realistic environments, such as simulation or on target hardware.
+
+## Determinism and Reliability
+
+- **Avoid Arbitrary Sleeps**: Never use arbitrary sleeps in tests, as they make them non-deterministic and flaky.
+
+- **Synchronization Mechanisms**: Instead of sleeping, use synchronization mechanisms or wait for the expected result with a proper timeout.
+
+- **Test Isolation**: Always use `ament_add_ros_isolated_gtest` to prevent cross-talk between parallel tests on the same network by assigning unique domain IDs.
+
+## Local Development
+
+- **Pre-commit Hooks**: Use pre-commit hooks to automatically run formatting, linters, and other fast checks before committing code. This helps catch issues early and reduces CI failures.
+
+## Continuous Integration
+
+The CI pipeline (e.g., **GitHub Action**s) serves as an enforceable quality gate.
+
+1. **Build**: Run colcon build to ensure the package and its dependencies compile correctly.
+
+2. **Test and Lint**: Execute colcon test. This triggers both the Static Analysis and the functional tests (Unit, ROS Unit, Integration).
+
+3. **Verification**: Use `colcon test-result --verbose` to interpret results.
+
+4. **Enforcement**: Configure branch protection rules to require these status checks pass before code can be merged.

README.md

@@ -6,6 +6,8 @@ It combines theory with hands-on exercises so that participants can directly app
 
 📑 The slides are available at [roscon_es_25_workshop_slides.pdf](roscon_es_25_workshop_slides.pdf)
 
+🤖 **AI-Ready**: Use our [AI Testing Guide](/AI_TESTING_GUIDE.md) to ensure your AI coding assistant follows **professional testing standards and testable design** in your own ROS 2 projects. See section [AI Assistants](#-ai-assistants) for more detail.
+
 ## 🚀 Motivation
 
 ROS projects are complex. They combine algorithms, drivers, middleware, and hardware interfaces into large, interdependent systems. In such an environment, even a small code change can have unintended effects. Without tests, these effects are only discovered late (often on a robot, at a demo, or by another developer) when the cost of fixing them is highest.
@@ -51,6 +53,18 @@ By the end of the workshop, participants will be able to:
 
 👉 It is recommended to review the official [ROS 2 Basic Tutorials](https://docs.ros.org/en/jazzy/Tutorials.html) beforehand.
 
+## 🤖 AI Assistants
+
+If you use AI coding assistants (ChatGPT, GitHub Copilot, Claude, Cursor, etc.), you can provide them with the engineering practices taught in this workshop to ensure generated code is testable and robust.
+
+See **[AI_TESTING_GUIDE.md](AI_TESTING_GUIDE.md)**
+
+Providing this document as context to an AI assistant helps it generate code and tests that follow these engineering practices.
+
+**Example prompt**:
+
+> I am developing a ROS 2 project. Act as a Senior Robotics Engineer. Before generating any code or tests, read AI_TESTING_GUIDE.md and strictly follow its guidelines regarding testable design, the testing pyramid, and deterministic execution.
+
 ## 📋 Workshop structure
 
 This workshop is organized into six modules that progressively develop the participant’s understanding of **testing in ROS 2**, from static analysis fundamentals to complete Continuous Integration pipelines.