Reading Code for Testers

Why it matters

Black-box techniques such as equivalence partitioning and boundary value analysis work from the requirement. They cannot see what the code actually compares, in which order it decides or where it stops early. Reading the code shows the decisions behind the partitions and boundaries you test, and exposes behaviour no requirement mentions: an extra discount, a forgotten case, an error that ends the function.

It also changes how you work with developers. You can review a change for the rules it touches, read a unit test and see what it really checks, and name the input and the line you suspect in a bug report. The white-box lessons that follow rely on it: they explain statement, branch and condition coverage with code written exactly like the snippets here and numbered the same way.

Values, variables and operators

A variable is a name for a value. const creates a name that cannot be given a new value; let creates one that can. Values have types: numbers (200), text strings ('SAVE10' or "SAVE10"), booleans (true and false) and two kinds of "nothing", undefined (never set) and null (empty on purpose). Text after // is a comment, a note for people that never runs. Read each snippet, then say it in plain words:

• const rate = 0.15; reads "rate is 0.15, and stays 0.15".
• let fee = 15; followed by fee = fee + 10; reads "fee starts at 15; take the current fee, add 10, store 25". A single = is assignment: it changes a value and never compares.
• const item = { price: 30, qty: 2 }; reads "item groups two named values, price 30 and qty 2", and item.price reads "the price of item". [30, 20] is a list (an array) of two values, [] is an empty list, and items.length is the number of values in items. const fixes only the name: the values inside a list or object can still change. In a calculation * multiplies and / divides: item.price * item.qty reads "the price of item times its qty".
• total === 200 reads "is total exactly 200?" and gives true or false; !== reads "is not". The double == also compares but converts types first, so '200' == 200 is true while '200' === 200 is false.
• total >= 200 reads "is total 200 or more?"; total > 200 leaves 200 itself out. Boundary defects often live in that one character.
• member && total >= 100 reads "a member and at least 100": true only when both sides are. express || urgent is true when at least one side is. !express reads "not express". && stops at the first false side and || at the first true one, so the second side may never be evaluated.
• a || b && c reads a || (b && c), because && is evaluated before ||. Brackets change the meaning, so read them carefully.
• if (qty) uses a value as a condition: 0, an empty string, null, undefined and NaN ("not a number", the result of a calculation such as 0 / 0 or 5 - undefined) count as false. A quantity of 0 is then treated like a missing quantity. The same rule hides in qty || 1, read "qty, or 1 when qty counts as false": || and && give back one of the two values themselves, not only true or false, so a quantity of 0 silently becomes 1.

Decisions: if, else, switch, return and throw

A decision chooses which lines run next. The lines between { and } form a block: the decision either enters it or skips all of it. Indentation only helps the eye, while JavaScript follows the braces: an if without braces controls only the one statement after it, however the next lines are indented. So when code arrives badly indented or minified into one long line, re-indent it before you trace it. In an if / else if / else chain the conditions are checked from the top; the first one that is true runs its block and the rest of the chain is skipped, even when a later condition would also be true. The order of the conditions is therefore part of the logic.

• if (total <= 0) { … } else if (total < 200) { … } else { … } reads "zero or less; otherwise under 200; otherwise everything else". Exactly one block runs.
• switch (coupon) { case 'SAVE10': …; break; case 'HALF': …; break; default: … } reads "compare coupon with each case using ===, run the first that matches, or default when none does". Without break, execution falls through into the next case; when nobody intended that, it is a classic defect.
• return fee; reads "stop here and hand fee back to the caller". Nothing after it in the same function runs, so an early return near the top skips everything below it.
• throw new Error('Order total must be positive'); reads "stop here with an error". The error travels to the code that called the function, which can catch it with try / catch; if nothing catches it, the operation stops, and in a browser the console reports an uncaught error. For a tester a throw is an expected result to check: the message, and what the user or the API client receives.

Try it: JavaScript Formatter Try it: Decision Table Generator

Loops, parameters and return values

A function is named logic with inputs and an output. Its parameters are the names in brackets, the arguments of a call are the values passed in, and the return value is what comes back. That maps directly onto testing: the arguments are your test inputs and the return value is the actual result you compare with the expected result. The coverage lessons also show TypeScript, which adds types after the names: total: number reads "total is a number", items: Item[] reads "items is a list of Item values" (Item is a type the team defined elsewhere), and ): number after the brackets reads "returns a number". TypeScript checks them before the code runs and removes them from the JavaScript that actually runs, so they do not check the values a call receives at run time, for example from an API response.

A loop repeats a block. A for loop has a start, a condition checked before every round and a step after every round; a while loop repeats as long as its condition is true. Both can run zero times.

• function deliveryFee(total, express) reads "a function named deliveryFee with two inputs". The call deliveryFee(200, false) sets total to 200 and express to false; a missing argument is undefined. A call inside the code, such as Math.floor(total / 10), runs another function and uses its return value; look built-in ones up on MDN (Math.floor rounds down: Math.floor(12.5) is 12).
• for (let i = 0; i < items.length; i++) { … } reads "start i at 0; while i is less than the number of items, run the block, then add 1 to i". Positions in a list start at 0: items[0] is the first item, items[i] the item at position i and items[items.length - 1] the last. Starting at 1 skips the first item; <= runs one round too many.
• for (const item of items) { … } reads "for each item in items, in order, run the block". It has no counter to get wrong, but an empty list still means zero rounds.
• while (attempts < 3) { … } reads "repeat while attempts is below 3". If nothing in the block changes attempts, the loop never ends and the page or the test hangs.
• Trace every loop with zero, one and several rounds: an empty cart, one item, many items.

Worked example: tracing a fee function by hand

Requirement: "Delivery costs 15.00 SAR. Orders of 200.00 SAR or more get free delivery. Express delivery adds 10.00 SAR, also to orders with free delivery. A total of zero or less is rejected." The developer's function is printed below the trace steps, with line numbers as in the coverage lessons; look up each line in it as you read the steps.

Make a trace table with one row per input and columns for the lines run, the outcome of each decision and the value returned. Walk the code one line at a time, writing down each variable's new value, and only then compare the return value with the expected result taken from the requirement. Pick inputs on both sides of every comparison:

• deliveryFee(0, false): on line 2, 0 <= 0 is true, so line 3 throws and lines 5 to 12 never run. The requirement expects a rejection: it matches.
• deliveryFee(50, false): all three decisions are false, fee stays 15 and line 12 returns 15. It matches.
• deliveryFee(250, true): line 6 is true, so fee becomes 0; line 9 is true, so fee becomes 10. It returns 10, as required.
• deliveryFee(200, false): 200 > 200 is false, so line 7 is skipped and the function returns 15 where the requirement expects 0. This input takes the same path as 50, and only the boundary value shows the defect. Run the test to confirm the failure, then report it with the input, the expected and actual results and line 6.

 1  function deliveryFee(total, express) {
 2    if (total <= 0) {
 3      throw new Error('Order total must be positive');
 4    }
 5    let fee = 15;
 6    if (total > 200) {
 7      fee = 0;
 8    }
 9    if (express) {
10      fee = fee + 10;
11    }
12    return fee;
13  }

Try it: Boundary Value Generator

Frequently asked questions

References

• ECMAScript® Language Specification (ECMA-262)Ecma International / TC39The JavaScript language standard, including the RegExp grammar and semantics, JSON.parse/JSON.stringify and the Date object.
• JavaScript — MDNMDN Web Docs (Mozilla)MDN's JavaScript guide and reference: the language's syntax, types, objects and built-ins as browsers implement them.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.