Add support for more test runners and linters

Open Beginner friendly
#3 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
rust
Domain
cli, testing-qa, tooling

Research direction

Choose one unchecked runner and start with CONTRIBUTING.md’s “adding a runner” walkthrough, then inspect src/runners.rs. Update classify() and parse_outcome() for that command, and add tests using real passing and failing output. Done means clear outcomes are recognised while ambiguous output returns Outcome::Unknown.

Written by the indexing model from the issue text.

Description

good first issue help wanted runner

backcheck can only verify a "tests pass" claim if it recognises the command that ran. Every
runner it does not know is a session where an honest claim looks unsupported, or a fabricated
one slips through.

This is the best first contribution to the project: self-contained, immediately useful, and the
same three steps every time.

Already supported

pytest, unittest, tox, nox, cargo test, cargo nextest, go test, jest, vitest, mocha, ava,
bun test, npm/yarn/pnpm test, rspec, phpunit, dotnet test, maven, gradle, ctest, make test —
plus mypy, pyright, tsc, ruff, eslint, clippy, flake8, pylint, golangci-lint, biome.

Wanted

Pick any one and open a PR — no need to claim it first, and one runner per PR is ideal.

  • deno test
  • swift test
  • xcodebuild test / xctest
  • elixir — mix test
  • scala — sbt test
  • haskell — stack test, cabal test
  • zig build test
  • julia — Pkg.test()
  • R — testthat, devtools::test()
  • perl — prove
  • bats (bash)
  • catch2 / gtest binaries
  • k6 / playwright test / cypress run
  • terraform validate, tflint
  • shellcheck, hadolint, yamllint
  • rubocop, standardrb
  • detekt, ktlint, spotless

How

All of it lives in src/runners.rs. See
CONTRIBUTING.md for the full walkthrough.

  1. Recognise the command in classify() — return the CheckKind and a short runner name.
  2. Read its outcome in parse_outcome() — pull pass/fail out of the summary line.
  3. Add a test with real passing and failing output, copied from an actual run.

The one rule

Return Outcome::Unknown when the output does not clearly say. A wrong "verified" is far more
damaging than an honest "could not tell" — backcheck is only worth installing if its
"supported" verdicts mean something.

Dominant language
Rust
Stars
0
Forks
2
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from VectorInstitute/backcheck

All issues in VectorInstitute/backcheck

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.