You inherited a codebase with tons of files and zero tests. Where do you even start?

Litmus tells you. Two commands, one ranked list — start testing where it actually matters.

dotnet tool install --global dotnet-litmus
dotnet-litmus scan

That's it. Litmus finds your solution, runs your tests, collects coverage, and hands you a prioritized action plan. No config files, no dashboards, no setup.

No tests yet? Even better — that's exactly what Litmus is for:

dotnet-litmus scan --no-coverage

Not another dashboard. Not a wall of warnings. A clear answer to "what should I test first?"

── Act Now ──────────────────────────────────────────────────────────────────────
Rank  File                           Commits  Coverage  Complexity  Coupling  Risk    Priority
1     Services/OrderService.cs       47       12%       94          Low       High    High
2     Services/ReportFormatter.cs    22       31%       67          Low       High    High

── Next Sprint ──────────────────────────────────────────────────────────────────
3     Controllers/PaymentGateway.cs  31       8%        118         Very High High    Medium

── Monitor ──────────────────────────────────────────────────────────────────────
4     Data/LegacyDbSync.cs           41       0%        201         Very High High    Low

4 files analyzed. 2 high-priority (start today), 1 medium-priority (next sprint).
2 high-risk file(s) need seam introduction before testing.

Act Now — high risk, low coupling. Write tests today. Next Sprint — high risk, but tangled. Introduce seams first, then test. Monitor — keep an eye on it, but don't start here.

Notice how PaymentGateway.cs has higher risk than OrderService.cs but lands in "Next Sprint"? That's Litmus telling you: "Yes, it's dangerous — but it's too entangled to test right now. Introduce seams first."

That's the insight you can't get from coverage reports alone.

Most tools tell you what's untested. Litmus tells you where to start — and what's blocking you.

It cross-references four signals that no single tool combines:

That last one is the key. Litmus uses Roslyn to detect unseamed dependencies — things like new HttpClient(), DateTime.Now, concrete constructor params — that make a file impossible to unit test without refactoring first. Then it adjusts the priority accordingly.

The result: a ranked list ordered by practical testability, not just risk.

dotnet-litmus scan --detailed

1  Services/OrderService.cs   47   12%   94   Low   High  High
     ProcessOrder             —    50%   25
     ValidateInput            —    0%    18

See exactly which methods inside a high-risk file need attention first.

dotnet-litmus scan --output baseline.json        # save a snapshot
dotnet-litmus scan --baseline baseline.json       # compare later

A Delta column shows what improved, what degraded, and what's new.

dotnet-litmus scan --explain

dotnet-litmus scan --output report.html           # shareable HTML with sortable table
dotnet-litmus scan --format json | jq '.[].file'  # pipe JSON to your tools
dotnet-litmus scan --output results.csv            # CSV for spreadsheets

• Auto-detects your solution file — just run from the project root
• One command does everything — tests, coverage, analysis, report
• Grouped output — Act Now / Next Sprint / Monitor
• Seam detection — knows when a file is too entangled to test directly
• Baseline comparison — track how test debt changes over time
• Method-level drill-down — pinpoint the riskiest methods
• Plain-English explanations — --explain tells you why each file ranks where it does
• Multiple formats — table, JSON, CSV, HTML
• CI quality gate — --fail-on-threshold breaks the build on risk regressions
• Flexible coverage — works with coverlet or dotnet-coverage
• No tests? No problem — --no-coverage works without any test projects

Litmus fits naturally into CI pipelines. Track test debt over time, catch regressions, and share reports with the team.

# .github/workflows/litmus.yml
- name: Install Litmus
  run: dotnet tool install --global dotnet-litmus

- name: Run analysis
  run: dotnet-litmus scan --output report.json --quiet

- name: Quality gate
  run: dotnet-litmus scan --fail-on-threshold 1.0 --quiet

Important: Use fetch-depth: 0 in your checkout step — Litmus needs full git history for churn analysis.

name: Litmus Analysis
on: [push]

jobs:
  litmus:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Install Litmus
        run: dotnet tool install --global dotnet-litmus

      - name: Download previous baseline
        uses: actions/download-artifact@v4
        with:
          name: litmus-baseline
        continue-on-error: true

      - name: Run analysis
        run: |
          if [ -f baseline.json ]; then
            dotnet-litmus scan --output report.json --baseline baseline.json
          else
            dotnet-litmus scan --output report.json
          fi

      - name: Save as next baseline
        uses: actions/upload-artifact@v4
        with:
          name: litmus-baseline
          path: report.json

Litmus analyzes your codebase in two phases:

Phase 1 — Risk Score: How dangerous is it to leave this file untested?

RiskScore = Churn × (1 - Coverage) × (1 + Complexity)

Phase 2 — Starting Priority: Can you actually test it today?

StartingPriority = RiskScore × (1 - Coupling)

A file with Very High coupling gets its priority reduced — not because it's safe, but because you need to introduce seams before you can test it. High risk + low coupling = start here.

For the full scoring methodology, seam detection signals, and architecture details, see ARCHITECTURE.md.

SonarQube monitors code quality. Litmus answers a different question: "I just inherited this codebase — where do I start testing?"

They complement each other well. Use SonarQube for ongoing quality gates; use Litmus to prioritize where to invest testing effort.

# From NuGet (recommended)
dotnet tool install --global dotnet-litmus

# From a local build
dotnet pack Litmus/Litmus.csproj -c Release
dotnet tool install --global --add-source Litmus/bin/Release dotnet-litmus

# Or run without installing
dotnet run --project Litmus -- scan

• .NET 8 SDK or later (.NET 9, .NET 10 supported)
• git on PATH
• For scan: test projects need coverlet.collector (or use --coverage-tool dotnet-coverage)
• For scan --no-coverage: no test setup needed at all

dotnet-litmus scan --solution path/to/MyApp.sln

dotnet add <test-project> package coverlet.collector

dotnet tool install --global dotnet-coverage
dotnet-litmus scan --coverage-tool dotnet-coverage

Contributions are welcome! Here's how to get started:

git clone https://github.com/ebrahim-s-ebrahim/litmus.git
cd litmus
dotnet build Litmus.slnx
dotnet test Litmus.slnx

Litmus eats its own dog food — the CI pipeline runs dotnet-litmus analyze on itself after every push.

Before submitting a PR:

• Run dotnet test Litmus.slnx and ensure all tests pass
• If adding a new feature, include tests in Litmus.Tests/
• Keep the architecture documented — see ARCHITECTURE.md

MIT