All the reading

Testing

7 lessons, about 33 minutes. The check's questions come from these.

Picking test targets

1. Pick what is worth testing

4 min

Key point

Test behaviour

A useful test proves something important your app does for a user. Do not start by asking “which files need tests?” Start by asking “what must not break?”

Recruiters trust tests when they protect real behaviour: login rules, price totals, form validation, permissions, API responses, and data changes.

What counts as worth testing

Your hackathon project does not need 100 tests. It needs a few tests that show you understand risk.

Pick things that are core to the app, easy to break while coding, or painful for users if wrong. A UPI split app must test amount splitting. A campus event app must test registration limits.

Your to-do

Find test ideas

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

List 3 main user actions in your app.
Mark the action that affects money, marks, bookings, access, or saved data.
Write the happy path for that action: valid input and expected result.
Write 1 or 2 failure paths: invalid input, missing data, or not allowed.
Keep only tests where a bug would matter to a real user.

0 of 5 done

Example

Tiny test plan

Before writing test code, write a plain test plan in your repo. This keeps you focused when you add Jest, Pytest, Vitest, or any other tool later.

Writing unit tests

2. Write your first unit test

5 min

What you test here

A unit test checks one small piece of code by itself. Usually this is a function that takes input and returns output.

For your hackathon repo, this is the easiest proof to add first. Pick business logic, not a button colour or a database call.

Key point

One idea

A good unit test proves one expected behaviour with clear inputs and a clear result. If it needs a server, a database, or a logged-in user, it is probably not a unit test.

Your to-do

Pick a function

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose a function with a clear job, like calculating fees, validating a phone number, or formatting a date.
Prefer code used by your app, not a new function written only for the test.
Avoid code that calls an API, reads files, or writes to a database for this lesson.
Write down one normal case and one edge case before you open the test file.

0 of 4 done

Test doubles and APIs

4. Use test doubles safely

5 min

Key point

One idea

Use a test double only when the real dependency makes the test slow, flaky, costly, or hard to control.

Do not fake the code you are trying to prove. Fake the outside thing your code talks to.

What doubles replace

A test double is a stand-in used during a test. It can replace an email sender, payment gateway, database, clock, file system, map service, or AI API call.

In hackathon projects, this often means you do not call Razorpay, Firebase, Google Maps, SendGrid, or an LLM API in a unit test. You replace that call with a small fake result.

Common mistake

CI and repo proof

6. Run tests on every push

5 min

Key point

One proof signal

A test suite is stronger when it runs without you clicking anything. Put it in CI so every push to GitHub runs the same test command.

Recruiters and mentors can then see a public commit, a workflow run, and a green check. That is better proof than saying “tests pass on my laptop.”

What CI does

CI means continuous integration. For this track, it only needs to do one job: install your project and run tests whenever code is pushed.

GitHub Actions is free enough for most student public repos. It reads a workflow file from your repo and runs the commands on a clean machine.

Your to-do

Before you add CI

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

10 questions, 7 to pass.

Feature: expense split

User action: Create a group expense

Worth testing:
1. Happy path
   Given amount = 900 and members = 3
   Expect each member share = 300

2. Rounding rule
   Given amount = 100 and members = 3
   Expect total assigned shares still equals 100

3. Invalid input
   Given amount = -50
   Expect the app rejects the expense

Not testing now:
- Button colour
- Exact wording of heading
- Animation timing

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to suggest test cases. Give it your feature, inputs, rules, and edge cases.

Check the answer. AI often suggests too many tests, tests private implementation, or ignores Indian product rules like rupee rounding, phone number format, or UPI-style flows.

Prompt:
I am building a college expense split app.
Feature: create expense.
Rules: amount is in rupees, members must be at least 2, shares must add up to the original amount.
Suggest 6 meaningful test cases.
Separate happy path, edge cases, and invalid input.
Do not suggest UI colour or layout tests.

Example

Example unit test

Here is a small JavaScript example using Vitest. The function calculates a simple platform fee in rupees.

The test has three parts: arrange the input, act by calling the function, and assert the expected output.

// src/calculateFee.js
export function calculateFee(amount) {
  if (amount <= 0) return 0;
  return Math.ceil(amount * 0.02);
}

// src/calculateFee.test.js
import { describe, it, expect } from 'vitest';
import { calculateFee } from './calculateFee.js';

describe('calculateFee', () => {
  it('returns 2 percent fee rounded up', () => {
    // arrange
    const amount = 101;

    // act
    const fee = calculateFee(amount);

    // assert
    expect(fee).toBe(3);
  });

  it('returns zero for zero or negative amounts', () => {
    expect(calculateFee(0)).toBe(0);
    expect(calculateFee(-50)).toBe(0);
  });
});

Your to-do

Run it locally

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Install Vitest if your JavaScript project does not already have a test runner.
Add a test script to package.json if it is missing.
Run the test command from your project root.
Read the failure message before changing code. It usually says what value was expected and what value was received.

0 of 4 done

npm install -D vitest

// package.json
{
  "scripts": {
    "test": "vitest run"
  }
}

npm test

Tip

Name tests plainly

Write the test name like a sentence: returns zero for negative amounts. A recruiter should understand the behaviour without opening the function.

If you use AI to draft tests, ask it for cases first, not code first. Then check that every case matches your actual product rules.

Prompt you can use:
I have this function. Suggest 5 useful unit test cases. Include normal cases and edge cases. Do not write code yet.

Then paste your function.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Find one pure function in your current project or create one from existing logic.
Write one test for the normal case and one test for an edge case.
Run the test locally until it passes.
Commit the function and test file together with a clear message.

0 of 4 done

git add src/calculateFee.js src/calculateFee.test.js package.json package-lock.json
git commit -m "Add unit test for fee calculation"

3. Choose unit or integration

5 min

Key point

One decision

A unit test checks one small piece of code in isolation. An integration test checks that two or more parts work together, like route plus database query, or service plus payment client wrapper.

The point is not to write the most tests. The point is to choose the cheapest test that gives real confidence.

Use unit when

Pick a unit test when the behaviour lives inside one function, class, or module. Good examples are price calculation, input validation, sorting, formatting, permission checks, and date logic.

These tests should be fast and boring. They should not need a server, database, network, browser, or real API key.

Use integration when

Pick an integration test when the risk is in the connection between parts. For example, your Express route may call the correct service, but return the wrong status code. Your app may save the right data, but read it back incorrectly.

Integration tests are slower, but they catch bugs that unit tests cannot. Use fewer of them, focused on important user flows.

Your to-do

Choose the level

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Name the behaviour in plain English, like "user can create an expense".
Ask where the risk is: inside logic, or between parts.
Choose unit if one function can prove it without real wiring.
Choose integration if you need the route, database, file system, queue, or another module to work together.
Write the test name before writing the test body.

0 of 5 done

Example

Same feature, two tests

Say your hackathon app splits a food bill for friends after a canteen order. The calculation is unit-test material. The HTTP endpoint that accepts the bill and returns the split is integration-test material.

This example uses JavaScript with Jest and Supertest. The exact framework can change. The choice stays the same.

// bill.js
function splitBill(totalRupees, people) {
  if (people <= 0) throw new Error('people must be positive');
  return Math.ceil(totalRupees / people);
}
module.exports = { splitBill };

// bill.test.js - unit test
const { splitBill } = require('./bill');

test('splits a bill and rounds up to the next rupee', () => {
  expect(splitBill(101, 4)).toBe(26);
});

// app.test.js - integration test
const request = require('supertest');
const app = require('./app');

test('POST /split returns per-person amount', async () => {
  const res = await request(app)
    .post('/split')
    .send({ totalRupees: 101, people: 4 });

  expect(res.status).toBe(200);
  expect(res.body.perPersonRupees).toBe(26);
});

Common mistake

Do not turn every test into an integration test because it feels more real. You will get a slow test suite that breaks for setup reasons, not product reasons.

Also avoid only unit tests. A repo with clean unit tests but no proof that the API works still leaves recruiters guessing.

Tip

Use AI carefully

You can ask an AI tool: "For this feature, suggest unit tests and integration tests separately." Paste the function or route code with no secrets.

Check its answer. Remove tests that repeat implementation details, depend on exact private function names, or need paid services. Keep tests that match user-visible behaviour.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open one feature from your current project.
Write two headings in a notes file: Unit tests and Integration tests.
List at least two behaviours under each heading.
Pick one unit test and one integration test you will add in later lessons.
Commit the notes file or add it to your project README as a short test plan.

0 of 5 done

Example

Small Node example

Here the code sends an OTP only after saving it. The test fakes the SMS service because sending a real SMS costs money and can fail for reasons outside your code.

The fake records what would have been sent. The test still checks real app behaviour.

// otp.js
async function sendLoginOtp(phone, store, smsClient) {
  const otp = "123456";
  await store.saveOtp(phone, otp);
  await smsClient.send(phone, `Your OTP is ${otp}`);
  return { ok: true };
}

module.exports = { sendLoginOtp };

// otp.test.js
const { sendLoginOtp } = require("./otp");

test("saves OTP and asks SMS client to send it", async () => {
  const saved = [];
  const sent = [];

  const fakeStore = {
    saveOtp: async (phone, otp) => saved.push({ phone, otp })
  };

  const fakeSmsClient = {
    send: async (phone, message) => sent.push({ phone, message })
  };

  const result = await sendLoginOtp("9876543210", fakeStore, fakeSmsClient);

  expect(result).toEqual({ ok: true });
  expect(saved).toEqual([{ phone: "9876543210", otp: "123456" }]);
  expect(sent[0].phone).toBe("9876543210");
  expect(sent[0].message).toContain("123456");
});

5. Test an API endpoint

5 min

Key point

One useful API test

An API test proves that a route works from request to response. It should send a request, let your route handler run, and check what the client gets back.

For your HackIndia repo, one good API test is better than five shallow checks. Pick a route that matters to your project, like login, create order, fetch notes, or submit feedback.

What to check

Check three things. First, the status code. Second, the response body. Third, the important side effect, if there is one.

For example, a UPI split app may test POST /expenses. The test should confirm 201, the returned expense amount, and that the expense was saved.

Your to-do

Set up the route

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Export your app without starting the server.
Start the server in a separate file, like server.js.
Install a request testing library for your stack.
Write the test against the app, not against localhost.
Run the test locally before you commit.

0 of 5 done

Example

Express example

This example uses Node.js, Express, Jest, and Supertest. The route is small, but the pattern works for bigger apps too.

Notice that app.js exports the app. It does not call listen. That makes the test fast and avoids port conflicts on your laptop or in CI.

// app.js
const express = require('express');

const app = express();
app.use(express.json());

const expenses = [];

app.post('/expenses', (req, res) => {
  const { title, amount } = req.body;

  if (!title || typeof amount !== 'number') {
    return res.status(400).json({ error: 'title and amount are required' });
  }

  const expense = { id: expenses.length + 1, title, amount };
  expenses.push(expense);

  return res.status(201).json(expense);
});

module.exports = app;

// server.js
const app = require('./app');
app.listen(3000, () => console.log('Server running on port 3000'));

// app.test.js
const request = require('supertest');
const app = require('./app');

test('creates an expense', async () => {
  const response = await request(app)
    .post('/expenses')
    .send({ title: 'chai for team', amount: 120 });

  expect(response.status).toBe(201);
  expect(response.body).toMatchObject({
    id: 1,
    title: 'chai for team',
    amount: 120
  });
});

test('rejects an invalid expense', async () => {
  const response = await request(app)
    .post('/expenses')
    .send({ title: 'chai for team' });

  expect(response.status).toBe(400);
  expect(response.body.error).toBe('title and amount are required');
});

Tip

Use AI carefully

You can ask ChatGPT or Gemini to draft API tests from your route file. Paste the route and ask for tests using your actual test runner.

Then check the output. It should import your app correctly, use real endpoint paths, await async calls, and assert status plus body. Do not accept tests that only check that a function was called.

Common mistake

Avoid weak tests

A weak API test sends a request and only checks 200. That misses broken response data, missing validation, and wrong error messages.

Also avoid testing against your running local server, like http://localhost:3000, unless you really need it. It is slower and can fail if the port is busy in your hostel Wi-Fi setup or CI.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Choose one important endpoint in your hackathon project.
Make sure your app can be imported without starting a server.
Write one success test with status code and response body checks.
Write one failure test for missing or invalid input.
Run the test locally and commit the test file.

0 of 5 done

Example

Node.js workflow

Create this file in your repo. Use it if your project has package.json and runs tests with npm test.

The workflow installs dependencies with npm ci, then runs your test script on every push and pull request.

# .github/workflows/tests.yml
name: Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Example

Python workflow

Use this version if your tests run with pytest. Keep a requirements.txt file in the repo, or change the install step to match your project.

If you use FastAPI, Flask, or Django, this same pattern still works. CI should run the command you already use locally.

# .github/workflows/tests.yml
name: Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

Common mistake

Green by accident

A workflow can pass even when it did not run your real tests. This happens when npm test only prints a message, or when pytest finds zero tests.

Open the workflow log after the first run. Look for your test runner output and the number of tests. Fix the script if CI is only pretending to test.

// package.json
{
  "scripts": {
    "test": "jest"
  }
}

7. Ship a tested public repo

4 min

Key point

Proof beats claims

A recruiter should not have to trust your resume line. Your repo should show the proof in under two minutes: tests exist, tests pass, and CI ran on the latest push.

Your goal is not to test everything. Your goal is to make the important behaviour visible and repeatable.

Your to-do

Repo checklist

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Make the repository public before you submit the project.
Keep the test files inside the repo, not only screenshots or local output.
Show at least one unit test for business logic or a helper function.
Show at least one API or integration test for a route, database flow, or service connection.
Keep the CI workflow file committed so every push runs the tests.
Check that the latest commit has a passing status before sharing the link.

0 of 6 done

What recruiters scan

They usually open your GitHub repo, then scan the README, file tree, and latest workflow status. Make those three things easy.

Use simple names. A folder called tests is easier to spot than random files hidden inside the app. If your framework uses __tests__ or spec files, that is also fine.

Example

README test section

Add a short section that tells someone how to run your tests locally. Mention what each test type covers.

Keep it honest. If your API test uses a test database or mock server, say so.

## Tests

This project includes:
- Unit test: validates price calculation in src/utils/calculateTotal.js
- API test: checks POST /api/orders returns 201 for a valid order
- CI: GitHub Actions runs tests on every push

Run locally:

npm install
npm test

Latest CI status: check the Actions tab for the latest run on main.

Common mistake

Do not fake confidence

Do not write “fully tested” if you only have two tests. Say what is covered.

Do not submit a repo where CI is red. A failing workflow tells reviewers that you did not check your own proof before sharing it.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to review your README and test names. Ask: “Can a recruiter understand what is tested in 60 seconds?”

Check the answer yourself. AI may suggest claims your repo does not prove. Remove any line that is not backed by a real file or CI run.

Your to-do

Before you submit

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open the repo in an incognito window and confirm it is public.
Click the Actions tab and confirm the latest run is green.
Open the test files and confirm names describe behaviour, not only implementation.
Run the install and test commands from a fresh clone if you have time.
Paste the repo link in your HackIndia submission, not a ZIP file.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Add or update the Tests section in your README.
Push your latest code and test files to GitHub.
Wait for CI to finish and confirm it passes.
Open your public repo link like a reviewer would.
Submit the repo link with your hackathon project.

0 of 5 done

Testing

1. Pick what is worth testing

Test behaviour

What counts as worth testing

Find test ideas

Tiny test plan

2. Write your first unit test

What you test here

One idea

Pick a function

4. Use test doubles safely

One idea

What doubles replace

6. Run tests on every push

One proof signal

What CI does

Before you add CI

Do not test everything

Use AI carefully

Do this now

Example unit test

Run it locally

Name tests plainly

Common mistake

Do this now

3. Choose unit or integration

One decision

Use unit when

Use integration when

Choose the level

Same feature, two tests

Common mistake

Use AI carefully

Do this now

Common mistake

Use safely

Small Node example

AI check

Do not fake contracts

Do this now

5. Test an API endpoint

One useful API test

What to check

Set up the route

Express example

Use AI carefully

Avoid weak tests

Do this now

Node.js workflow

Python workflow

Use AI carefully

Green by accident

Do this now

7. Ship a tested public repo

Proof beats claims

Repo checklist

What recruiters scan

README test section

Do not fake confidence

Use AI carefully

Before you submit

Do this now