Unit and API tests usually form the backbone of fast feedback in CI, and GitHub Actions makes it straightforward to run them on every push or pull request. As a QA engineer, you should know how to wire these suites into jobs that are reliable and easy to read.
Configuring Jobs for Unit and API Tests
You can create separate jobs for unit and API tests or combine them in one job, depending on runtime and tooling. The important parts are setting up the right language runtime, installing dependencies and running your test commands with clear output.
# .github/workflows/backend-tests.yml
name: Backend Tests
on:
pull_request:
branches: [ main ]
jobs:
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- name: Install deps
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Run unit tests
run: pytest tests/unit --maxfail=1 --disable-warnings -q
api-tests:
runs-on: ubuntu-latest
needs: unit-tests
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- name: Install Newman
run: npm install -g newman
- name: Run API tests
run: newman run postman_collection.jsonneeds: to ensure API tests only run if unit tests pass; this keeps feedback focused and avoids noisy failures.Over time, you can extend these jobs with coverage reporting, environment variables and secrets for authenticated calls.
Common Mistakes
Mistake 1 — Mixing too many concerns into one job
This reduces clarity.
❌ Wrong: Running unit, API and UI tests all in a single long step.
✅ Correct: Use separate jobs or at least separate steps with clear names and commands.
Mistake 2 — Not failing the job when tests fail
This hides problems.
❌ Wrong: Using shell tricks like || true that swallow exit codes from test runners.
✅ Correct: Let the test command exit with a non-zero code so GitHub Actions marks the job as failed.