JavaScript Basics for Testers

1 The Hook

Tama moved from manual testing into a small automation squad at a Christchurch fintech. His first real test logged into a fictional banking app, clicked “Pay”, and checked that a success message appeared. He wrote it, ran it, and it passed. He ran it again — it failed. Ran it a third time — passed. Same code, same app, different result each time. To a manual tester, that is maddening: nothing changed, so why did the answer change?

He showed it to a senior tester, who read the script in about ten seconds and said: “You’re not waiting for the message. The app takes a moment to show it, and your test checks before it appears. Sometimes the message is up in time, sometimes it isn’t — that’s your flaky test.”

The fix was one word: await. The script needed to wait for the success message to appear before checking for it. Tama had written the steps in the right order, but he had not told the test to pause for the app to catch up — and that gap between “asking the app to do something” and “the app actually finishing it” is the single most important idea in reading test code.

Here is the lesson hidden in that story: a test script is not a list of instant actions. Some steps take time, and the test has to wait for them. Once you understand variables, functions, and waiting, you can read almost any test script and see what it is doing — and why it sometimes goes flaky. That is what this lesson teaches.

2 The Rule

3 The Analogy

4 Variables — Naming Things

A variable is just a name you give to a value so you can use it again. In JavaScript you create one with const or let, a name, an equals sign, and the value:

The difference between the two: const is for a value that will not be reassigned (most of the time, use this), and let is for a value you expect to change later. The values themselves come in a few everyday types: text (called a string, always in quotes), numbers, and true/false (called a boolean). The // marks a comment — a note for humans that the computer ignores.

Why testers care: test scripts use variables to hold things like the username they log in with, the expected total, or the element they just found, so the same value can be reused across several steps without retyping it.

5 Functions — Reusable Steps

A function is a named group of steps you can run whenever you want. Think of it as a saved procedure — like a reusable test step. You define it once and “call” it by name as many times as you like:

Read it piece by piece: function declares it, greet is the name, (name) is the parameter — a value you hand in when you call it — and the part in curly braces { } is the body, the steps it runs. return is the answer it hands back. When you write greet('Aroha') you are calling the function with 'Aroha' as the name.

You will also meet a shorter style called an arrow function, which is the same idea written more compactly — you will see it a lot in test files:

Why testers care: every test you write is a function. When you see test('user can log in', async () => { ... }), the part in braces is the body of a function — the steps of that one test.

6 Common Syntax You’ll See

You do not need to memorise a language. You need to recognise the handful of symbols and shapes that show up in every test file. Here is the cheat sheet:

The dot is worth dwelling on, because test scripts are full of it. page.goto('...'), page.click('#buy-now'), expect(total).toBe(120) — each is “take the thing on the left, run the action on the right.” Once that clicks, most test lines read almost like English: “on the page, click the buy-now button.”

7 Async, Await & Promises — Why Tests Wait

This is the section that matters most, because it is the idea behind nearly every flaky test. Some actions finish instantly — adding two numbers. Others take time — loading a page, clicking a button that talks to a server, waiting for a message to appear. JavaScript handles the slow ones with three connected words:

• A promise is an IOU. When you ask the app to do something slow, it does not hand back the result immediately — it hands back a promise: “I’ll get back to you when this is done.” (Like the café taking your order.)
• await means “pause here until that promise is fulfilled.” It is you waiting for your name to be called before collecting the coffee. After an await, you know the action has actually finished.
• async is a label on a function that says “this function contains waiting.” You can only use await inside a function marked async. That is why almost every test starts with async () => { ... }.

See the difference in one example. Without await, the test races ahead:

With await, the test waits for each slow step to finish before moving on:

That one word was Tama’s whole bug. The actions were in the right order; the test just was not waiting for the slow ones to finish.

8 Reading a Simple Test Script

Now put it together. Here is a complete, simple test for a fictional Kiwibank online-banking login. You will not write this yet — the goal is to read it and narrate what each line does.

Read it as a story: this is a test named “customer can log in”; it is async because it waits. It names the login email in a variable, opens the page, fills the username and password fields, clicks the login button, then waits for and checks that a welcome message appears. Notice every action that talks to the app is preceded by await — that is what makes it reliable. The #username, #password, and #login-btn are CSS-selector locators — exactly what you learned in Lesson 1. The two lessons meet right here.

9 Common Mistakes

10 Now You Try

Three graded exercises — spot it, fix it, build it. Write your answer, run it for AI feedback, then compare to the model answer.

Line 1: Opens (navigates to) the Trade Me listing page at that URL and waits for it to load.

Line 2: Clicks the "Watch" button, found by its data-testid locator "watch-button", and waits for the click to be handled.

Line 3: Waits for the element with class "watch-status" to show the text "Watching", and checks that it does. This is the assertion — the actual test of whether watching worked.

Why every action has await: Each of these actions talks to the live app and takes time — loading a page, handling a click, the status updating. They return promises (IOUs). await pauses the test until each one actually finishes, so the next line does not run before the app is ready. Without await on line 3, the test could check the status before it updated and fail randomly — a flaky test.

Bonus: the test is marked async (async () => {...}) precisely because it uses await inside.

My corrected test:
test('payment shows confirmation', async () => {
  await page.goto('https://myir.example.nz/pay');
  await page.click('#pay-now');            // added await
  await expect(page.locator('.confirmation')).toBeVisible();
});

What was wrong and why my fix works:
The click on #pay-now was missing its await. Clicking "Pay now" talks to the app and takes time, so it returns a promise. Without await, the test fires the click and immediately races on to check for the confirmation — sometimes the confirmation has appeared in time (test passes), sometimes it has not (test fails). That randomness is the flakiness. Adding await in front of page.click('#pay-now') makes the test wait for the click to be handled before moving on, so by the time it checks for the confirmation the app has had its chance to respond. Reliable every run.

Note: do NOT "fix" it by adding a fixed sleep — await the real action, not a guessed delay.

Step 1 — Open the RealMe login page — needs await? YES (loading a page takes time) — rough code: await page.goto('https://realme.example.nz/login');

Step 2 — Type the username into the username field — needs await? YES (it talks to the app) — rough code: await page.fill('#username', 'aroha@example.nz');

Step 3 — Type the password into the password field — needs await? YES — rough code: await page.fill('#password', 'CorrectHorse1');

Step 4 — Click the "Log in" button — needs await? YES (the click is handled by the app) — rough code: await page.click('#login-btn');

Step 5 — Confirm the "Welcome back" heading appears — needs await? YES (you must wait for it to show before checking) — rough code: await expect(page.locator('h1')).toHaveText('Welcome back');

Marking guide: full marks for a sensible ordered flow where EVERY app-touching step (goto, fill, click, the final check) is marked as needing await, with locators that look like CSS selectors (#username, #login-btn). The key learning: in a UI test, nearly every step talks to the app and so needs await. The only things that would NOT need await are pure in-memory steps like naming a variable (const username = '...').

11 Self-Check

Click each question to reveal the answer.

12 Interview Prep

Real questions asked in NZ QA interviews for junior automation roles. Read the model answers, then practise your own version.