The core functions, written test first

Writing the check before the code sounds backwards, and the usual explanation - 'it catches bugs' - undersells it. The real effect is that you have to decide what the function is called, what it takes and what it hands back before you can write a single line of the body. You become the first person to use your own function, at the moment when changing your mind is still free.

That is why awkward designs get caught here. If the check is painful to write - if you need three lines of setup, or you cannot say what the result should be without a paragraph of explanation - the function is badly shaped, and you have found out before writing it rather than after building three more on top of it.

The second effect is the one people mention: a check you watched fail, and then watched pass, is wired to the behaviour. A check written afterwards has never failed, and a check that has never failed might be testing nothing at all. That is not a hypothetical - a typo in a function name gives you a check that passes for the wrong reason, and you will never notice unless you saw it red first.

The loop has three steps and they are always in this order. Write one check for one behaviour and run it: it fails, because the behaviour does not exist yet. Write the smallest code that makes it pass - genuinely the smallest, even if it is embarrassing. Then, with the check green, tidy the code up, knowing that if you break something the check will tell you.

Then repeat for the next behaviour. Each cycle is minutes, not hours. Nothing here needs a framework: your check is a function that compares two values and prints PASS or FAIL, exactly like the one you wrote in module 11.

The discipline that makes this work is doing one behaviour at a time. Writing eight checks and then eight function bodies puts you back where you started - a big pile of code with no idea which part is wrong. One check, one body, run it, next.

The best first check for any function that takes a list is the empty list. It looks like an edge case and it is really a design question: what does summarise of an empty log mean? Zero pages and zero minutes, with an empty list of titles? Or null, because there is nothing to summarise? Or an error?

Answer it now, deliberately, and the rest of the function follows from the answer. Answer it by accident - by writing the loop first and seeing what falls out - and you get whatever your code happened to do, which is usually undefined leaking into somebody else's arithmetic three functions away.

For readlog the answer is: zeros and an empty list. A log with no sessions has read zero pages, which is a true and useful statement, and it means every caller can add up results without checking for a special case first. That is the test of a good empty answer: it keeps the caller's code simple.

Adding up a list has two spellings and they do the same thing. The plain one: declare a total with let before the loop, walk the list with for...of, and add to it. The compact one: reduce, which takes a function saying how to combine the running total with the next item, plus the value to start from.

The value to start from is the part worth understanding. MDN's edge-case note is explicit: if an initial value is provided and the array is empty, that value is returned without ever calling your function. So [].reduce((total, value) => total + value, 0) is 0, not an error and not undefined - the empty case is handled by the 0 you wrote, which is why you should always supply it.

Leave the initial value out and reduce on an empty array throws a TypeError instead. That is the whole argument for always passing it: with the initial value your empty case is a value you chose, without it your empty case is a crash.

Which spelling to use is taste, not correctness. A running total is easier to read when you are collecting several things at once - readlog needs pages, minutes and titles from one pass - and reduce reads better when there is exactly one thing to build.

Sorting is where the polite habit of not touching your caller's data usually breaks. MDN says it plainly: sort sorts the elements in place and returns a reference to the same array, now sorted. It does not hand back a tidy copy and leave the original alone - there is no copy at all.

So titles.sort() reorders titles, and if titles came from the caller you have just rearranged their data as a side effect of asking a question. That is the kind of bug that shows up far away from its cause: some other function that assumed the original order now reports something subtly wrong, and nothing in that function is wrong.

Two safe habits. Sort only arrays you built yourself inside your own function - a list you assembled from the caller's data is yours, and sorting it is fine. Or copy first with slice() and sort the copy. Both are one word longer than the unsafe version.

There is a second surprise in the same method: the default order is not numeric. MDN states that without a compare function the elements are converted to strings and compared by UTF-16 code units, which is why [10, 9].sort() gives [10, 9] and not [9, 10]. Sorting titles is text, so the default is exactly right here - just never trust it for numbers.

A check called 'test 3' tells you nothing when it goes red in a month. A check called 'an empty log reports zero pages' tells you which promise just broke, without opening the code. The label is not decoration, it is the failure message.

Write it as a claim about behaviour, in the words of the brief. 'titles holds each book once, sorted' is good. 'summarise works' is not - when it fails you learn only that something, somewhere, is wrong.

The graded exercises in this course follow the same rule: every hidden assertion has a description written to be readable on the day it fails. When one of them goes red, the description alone should tell you what to fix.

Write the check first, watch it fail, write the smallest code that makes it pass, then tidy up. The empty list is the first check because it forces you to decide what the result means when there is nothing - and zeros keep the caller's code simple. Totals come from a running variable or from reduce with an initial value, which is what makes an empty array safe. sort reorders the array it is given and returns that same array, so sort only what you built yourself, or copy first. Name every check after the promise it defends.