Testing

The Big Idea

Testing is how you know your code works — not just now, but after future changes. In this primer you will learn what testing is, what unit testing and test-driven development mean, and why developers treat untested code as incomplete.

Your Roadmap

What is testing?

Testing is code that checks your code. Instead of manually running your program and eyeballing the output, you write a function that says: "When I call this code with this input, I expect this output."

function testGreeting() {
  const expected = 'Kia ora Cam!'
  const actual = greeting('Cam')

  if (actual !== expected) {
    console.log("It's broken..")
  } else {
    console.log('It works!')
  }
}

A function that passes this test:

function greeting(name) {
  return 'Kia ora ' + name + '!'
}

During Foundations, most of your testing will be manual — running code and using console.log to check what is happening. But understanding automated testing now means the kata challenges this sprint will make more sense.

Unit Testing

Unit testing tests one small piece of code at a time — one function, one unit.

Rather than testing whether your whole application works, unit tests check that each small part does exactly what it should. When every unit is reliable, the larger program built from those units is reliable too.

When you make a change to your code and all your unit tests still pass, you can feel confident you have not broken anything — provided your tests cover the right cases.

Test-Driven Development

Test-Driven Development (TDD) means writing your tests before you write your code.

The process:

1. Decide what a function should do
2. Write a test for that behaviour
3. Run the test — it fails (you haven't written the code yet)
4. Write the minimum code to make the test pass
5. Refactor the code to make it clean
6. Repeat for the next feature

TDD forces you to think clearly about what your code needs to do before you write it. It also means you can try different approaches freely — as long as the tests pass, you're on track.

You will not write your own tests until Bootcamp. In the kata challenges this sprint, the tests are already written — your job is to write the code that makes them pass.

Check your understanding with a chatbot

Open your chatbot and work through these steps in order:

Step 1 — Tell it where you are:

"I've just read an introduction to testing in JavaScript — unit testing and TDD. I haven't written any tests yet. Quiz me with 3 questions to check my understanding. Don't explain anything yet, just ask the questions."

Step 2 — Answer its questions in your own words. Don't look anything up. Just answer from what you remember. It's fine to say "I'm not sure."

Step 3 — Ask it to fill the gaps:

"Based on my answers, what's the one thing I'm most unclear on? Explain just that one thing in plain language with an analogy."

Step 4 — Check your analogy:

"I think unit testing is like [your analogy]. Is that accurate? What does my analogy miss?"

Reflect

Add your answers to your my-reflections-sprint-4 file under the Testing heading. Commit and push to GitHub.

The Big Idea (revisited)

Testing is how you know your code works — not just now, but after every future change. Untested code is incomplete code.

Extra Resources

These are optional. Use them if you want to go deeper.

• ◎ What is TDD and why should we care about it?
• ◎ How to write a good unit test