Testing your own code.

A test has exactly two things.

It doesn't matter what language you use, what framework, what company. Every test in the world boils down to two values sitting side by side: the answer you expect, and the answer the code actually got. If they match, pass. If they don't, fail.

Notice what the second card tells you. Not just "something's wrong" — it tells you exactly what went wrong. You wanted 5. You got "23". That's immediately a clue: somewhere in the code, the numbers are being treated as text and concatenated instead of added. A good test turns a bug into a clue.

Three kinds of test you should always have.

These are the same three categories from Skills Workshop Builders 01 — happy path, edge case, failure — but now written as real JavaScript. A test suite with only happy paths is a lie. A test suite with all three is worth trusting.

Here's a real test file for a real function.

The function counts how many vowels are in a word. Below it, six tests — two happy paths, two edge cases, two failures. Every test uses the same two-step shape: call the function, check the result.

// The function we're testing
function countVowels(word) {
  if (typeof word !== "string") return null;
  const vowels = "aeiouAEIOU";
  let count = 0;
  for (const char of word) {
    if (vowels.includes(char)) count++;
  }
  return count;
}

// A tiny test runner — just expect() and test()
function expect(got) {
  return {
    toBe(expected) {
      if (got === expected) return { pass: true };
      return { pass: false, got, expected };
    }
  };
}

// ============ HAPPY PATHS ============

test("counts vowels in a normal word", () => {
  expect(countVowels("hello")).toBe(2);
});

test("counts vowels in a longer word", () => {
  expect(countVowels("encyclopedia")).toBe(6);
});

// ============ EDGE CASES ============

test("empty string returns zero", () => {
  expect(countVowels("")).toBe(0);
});

test("word with no vowels", () => {
  expect(countVowels("rhythm")).toBe(0);
});

// ============ FAILURE CASES ============

test("rejects a number", () => {
  expect(countVowels(42)).toBe(null);
});

test("rejects null", () => {
  expect(countVowels(null)).toBe(null);
});

Read it top to bottom. The real countVowels function lives at the top — about eight lines. Below it, a tiny expect() helper we wrote ourselves (professional tools like Jest do the same thing, just fancier). Then six tests, grouped by kind. The tests are longer than the function. That's normal. Good code is always more tested than written.

Write a function. Write tests. Click Run all.

This is a real test runner. The left side has two editable pieces: a function you're testing, and a list of test cases. Click "Run all" and every test runs in a real sandbox — you'll see which ones pass, which ones fail, and exactly what the failing ones got instead.

Yes — the test runner uses real new Function() sandboxing under the hood. Your function and your tests both run in a real browser JavaScript engine. This isn't a simulation. You're writing real code that really runs.

Not all tests are good tests.

A bad test is worse than no test — it lies to you. It says "passing" when your code is broken. Two rounds of judgment.

In Module 04 — the last Code Club module, the Builders finale — you'll put all of it together to build something other people can actually use: a real tool. Your own small app, with tests, a real URL, and a README. That's the graduation project of Code Club.