dartsim/dart

Overview

This skill encapsulates the DART testing patterns and commands used to write, run, and debug unit and integration tests for the DART codebase. It provides quick test commands, conventions for test organization and naming, and CI validation steps to ensure tests and linters pass before submitting PRs. Use it to speed up local development and reproduce CI failures reliably.

How this skill works

It collects the common test workflows: quick runs, full validation, and targeted test execution using ctest and the pixi task runner. It describes where tests live (unit, integration, and regression) and the recommended GoogleTest naming and structure. It also lists commands and steps for reproducing CI issues and retrieving CI logs for debugging.

When to use it

• When adding or modifying code that requires unit or integration tests.
• Before opening a PR to ensure linting and full test suites pass in CI.
• When a CI job fails and you need to reproduce and diagnose the failure locally.
• When writing regression tests that should live near the code they validate.
• When you need to run a specific test or view verbose output to track down flaky behavior.

Best practices

• Follow existing patterns in tests/unit and tests/integration to keep consistency.
• Use GoogleTest and name tests descriptively: ClassName_MethodName_Condition_ExpectedResult.
• Run linting and the full test suite locally (pixi run lint; pixi run test-all) before pushing changes.
• Place regression tests close to the code they validate to make future maintenance easier.
• Use ctest -R <pattern> -V to run and debug a single test with verbose output.

Example use cases

• Quick validation: pixi run test to run a small subset during development.
• Full CI-like validation: pixi run test-all to catch integration issues before a PR.
• Targeted debug: ctest -R MyTest -V to reproduce and inspect a failing test.
• CI log retrieval: gh run view <RUN_ID> --log-failed to fetch logs for a failed workflow and correlate with local failures.
• Adding a regression test next to modified code to prevent future regressions.