Testing - lesson 3 | HackIndia Skills

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.