Splitting the parsing logic from the IO is the design choice that makes this prompt testable. interpretAnswer is a pure function: same input always produces the same output, so the matrix of edge cases (empty string, mixed case, whitespace, junk) is cheap to verify in unit tests. The default-answer parameter is what gives the prompt the right semantics for destructive operations: confirm('Drop database?', { default: false }) defaults to no, so a fat-finger Enter does not nuke the DB. The [y/N] capitalization in promptHint is a convention every veteran terminal user reads as 'default is no'.

The Promise wrapper is the whole trick. readline.question is callback-shaped, but every modern script wants await confirm(...); the resolve in the callback bridges the two without pulling in util.promisify. Injecting the line-getter (rather than calling readline directly) is what lets the same code run under tests, under a fake stdin, or under the real terminal; the production version literally substitutes readline.question for the fake readLine in the snippet. I have shipped this exact split in three deploy scripts; the pure parser caught two off-by-one bugs in interactive code that would have been unfindable with stdin in the loop.