Skip to content

Latest commit

 

History

History
114 lines (81 loc) · 2.34 KB

File metadata and controls

114 lines (81 loc) · 2.34 KB

Testing Guide

Quick guide for running tests in this project.

Quick Start

# Install dependencies
pip install -e ".[dev]"

# Run fast tests (recommended during development)
pytest -m unit

# Run all tests (except slow ones)
pytest -m "not slow and not full_pipeline"

# Run everything
pytest

Test Categories

Marker Speed
unit <1s per test
integration 1-5 min
slow >5 min
full_pipeline 30+ min

Common Commands

Development Workflow

# Fast feedback loop (unit tests only)
pytest -m unit

# Test specific file
pytest tests/unit/test_bids_parsing.py

# Test specific function
pytest tests/unit/test_bids_parsing.py::test_parse_subject_id

Useful Options

# Stop on first failure
pytest -x

# Show which tests are slowest
pytest --durations=10

# Run tests matching a pattern
pytest -k "motion_correction"

Test Data

Test data is stored in tests/data/.

Coverage Requirements

  • Overall: >85%
  • Unit tests: >90%
  • Integration tests: >80%
# Check coverage
pytest --cov=src --cov-report=term-missing

# Generate HTML report
pytest --cov=src --cov-report=html

CI/CD

Tests run automatically on GitHub Actions:

  • On every push: Unit tests + fast integration tests
  • Manual trigger: Full pipeline tests (slow)

To run the same tests as CI locally:

pytest -m "not slow and not full_pipeline" \
  --cov=src \
  --cov-report=xml \
  --junitxml=pytest.xml

Directory Structure

tests/
├── conftest.py              # Shared fixtures
├── unit/                    # Fast tests (<1s)
├── integration/             # Medium tests (1-5 min)
├── full_pipeline/           # Slow tests (30+ min)
└── data/                    # Test datasets

Best Practices

  1. Run unit tests frequently - They're fast (<1s)
  2. Run integration tests before committing - Catch issues early
  3. Use appropriate markers - Auto-applied based on file location
  4. Write descriptive test names - test_motion_correction_preserves_dimensions
  5. One assertion per test - When practical
  6. Use fixtures - Don't repeat setup code
  7. Keep tests independent - No shared state between tests