Testing and deployment - bringing the project before the world

The capstone is built - but running on your own machine and staying up for everyone are not the same thing. Today is that final bridge: some testing, so that when code changes later you know whether the old stuff broke; and deployment discipline, so there is no last-minute rush when going live.

Testing - the minimum you cannot skip

You do not have to test everything. Start with the most valuable places - where calculation and rules live: price calculation, the status-change chain, validation. These logic parts are easy to test, because without a database you can just match input to output.

// A small unit test with Vitest
import { describe, it, expect } from "vitest";

describe("calculateTotal", () => {
  it("adds item prices and the delivery charge", () => {
    const total = calculateTotal(
      [{ price: 220, qty: 2 }, { price: 60, qty: 1 }],
      60 // delivery charge
    );
    expect(total).toBe(560);
  });
});

Environment variables and the production checklist

Database addresses, JWT secrets, API keys - these live in environment variables, not in code, and change with the environment. Never push a .env file to Git; instead keep a .env.example, which has only the names, not the values. Before deploying, go through this list:

• All secrets in environment variables, not a single one in code
• Database migrations run on production
• CORS only for the real frontend domain, rate limit on
• Errors must not show the user internal details (stack traces)
• Logging on - if something breaks, will you be able to find it?
• A health check endpoint exists - can you tell from outside whether the server is alive

The last job is small but valuable: write a good README. What the project is, what features it has, how to run it, why which decisions were taken. Interviewers opening GitHub read the README first - it is your project's face.

The mistake everyone makes

Writing secrets in code and pushing them to GitHub - once uploaded, they stay in history, even if you delete them. Another mistake: leaving the README empty. Even a great project, if it cannot be explained, gets the value of an ordinary project.

Today's practice

Write at least 3 unit tests on the capstone's calculation parts. Verify once against the checklist above. Then write the README - features, how to run, and the reasons for the three most important decisions.

How to say it in an interview

Test yourself: 'I keep unit tests on the core logic, I keep all secrets in environment variables, and before deploying I go through a fixed checklist - migration, CORS, rate limit, logging, health check. I also write the reasons for decisions in the README.'