Tests, CI Badges and Linting

Evidence of engineering habits

Tests, a linter and a continuous integration (CI) workflow that runs them on every push show that you care about correctness and maintainability. You do not need full coverage on a portfolio project; a focused set of meaningful tests for the important logic is more convincing than many trivial ones. A status badge in the README shows whether CI passes; only show it if you keep it green. Add a linter and formatter so the code style is consistent, and a short "How to run tests" section in the README. Be ready to explain in interviews what you chose to test and why.

A minimal GitHub Actions workflow

A Node.js project example; check the GitHub Actions docs and action versions for your setup.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test

# README badge (replace OWNER and REPO):
# ![CI](https://github.com/OWNER/REPO/actions/workflows/ci.yml/badge.svg)

A red badge is worse than none

A failing CI badge on a pinned repository suggests the project is broken. Fix the build or remove the badge before you apply.

Quick check: What makes tests in a portfolio project most convincing?

• Hundreds of trivial tests to boost coverage
• Meaningful tests for the important logic, run automatically in CI
• Tests that are commented out
• A badge that says tests pass without any tests