9.2 — The terminal, properly
Every automation tester’s day starts in the same window: the terminal — a text conversation with the operating system. Run the suite from it, read the failures in it, and understand the one NUMBER it leaves behind — the exit code CI lives by.
Today: the four commands you’ll actually use, how to read a stack trace without flinching (spoiler: it’s 3.6’s tower, printed), and why 0 means green.
$ pwd
/Users/lijas
$ cd shop-tests
$ ls
package.json tests/ report.js
$ node report.js
ReferenceError: totl is not defined
at makeReport (report.js:4:15)
at main (report.js:9:3)
at report.js:12:1
$ echo $?
1The terminal is a text conversation with the operating system: you type a command, it answers in text. No buttons, no icons — which is exactly why machines (and CI servers) love it: everything is scriptable, repeatable, loggable.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
The terminal window and the program interpreting your commands are technically two things — the interpreter is called a shell (bash and zsh on Mac/Linux, PowerShell on Windows). Same conversation, slightly different dialects: ls vs dir, $? vs $LASTEXITCODE. The concepts today are identical in all of them.
A handful of extra commands covers 95% of daily work: mkdir name (make a folder), cat file (print a file’s contents), Tab to autocomplete paths, ↑ to repeat history, and Ctrl+C to stop a running program. Learn the Tab key especially — professionals never type full paths.
Exit codes compose: in CI configs you’ll see npm test && npm run deploy — the && is 2.4’s guard working on programs: deploy runs only if tests exited 0. The same short-circuit logic, one level up.
Job note: when a Playwright test fails in CI, what you get is exactly today’s artifact — a terminal log with stack traces, and a red pipeline driven by the exit code. Reading traces calmly, innermost frame first, is the debugging skill interviewers quietly test with “walk me through this failure.”
⌨️ the CI verdict machine
CI never reads test output — it reads ONE number. Model the contract: a suite produces an exit code, and CI turns that code into a verdict.
requirements:
- Write
runSuite(failures): given how many tests failed, return the exit code —0when nothing failed,1otherwise. - Write
ciVerdict(code): return"green"for exit code0,"red"for anything else. - Print, in order:
runSuite(0),runSuite(3), then the verdict of a clean run, then the verdict of a run with 3 failures — always passing runSuite’s answer into ciVerdict.
when you press RUN, the console must show exactly:
✏️ Quick check 1
A program finishes with exit code 0. Did it succeed or fail?
✏️ Quick check 2
In the trace line "at makeReport (report.js:4:15)" — which LINE of the file did the crash happen on?
✏️ Quick check 3
Which command lists the contents of the folder the terminal is standing in (Mac/Linux)?
🗣️ Now teach it back
Explain to a friend how to read a terminal stack trace line by line (what each part is), and how CI uses exit codes to decide pass or fail without reading any output.
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.