Q432: Implementation Drill Console Cap Test Plan

What Interviewers Want To Evaluate

This drill tests whether you can plan tests for worker-based console behavior without overcomplicating the implementation.

Console caps are now shipped in the practice ground.

The next step is deciding what should be tested automatically and what should remain manual until the architecture is ready.

Short Interview Answer

I would test console cap behavior in layers.

Pure formatting and truncation helpers can be unit tested if they are extracted.

Worker execution can be covered with integration or browser tests later.

For now, I would keep a manual QA script for timeout and browser behavior, then extract output formatting if repeated logic grows.

Why Console Tests Are Different

Editor transforms are pure.

Console execution is not pure.

It involves:

Web Worker
Blob URL
timeout
console monkey patching
runtime errors
browser APIs
copy behavior

That means a Node-only unit test is not enough for the whole feature.

Choose the right layer.

What Can Be Unit Tested

If extracted, test:

message truncation
entry cap logic
system truncation message
visible output copy formatting
line classification

These are deterministic.

They do not require a real browser.

They can use the same lightweight test runner as editor transforms.

What Needs Browser Or Manual QA

Keep browser/manual checks for:

worker creation
worker termination
timeout recovery
Blob URL cleanup
console capture inside worker
copy to clipboard
dark mode readability
mobile layout

These depend on browser behavior or visual review.

Do not fake so much that the test stops proving real behavior.

Suggested Next Refactor

If console code grows, extract:

MAX_CONSOLE_LINES
MAX_CONSOLE_MESSAGE_LENGTH
formatConsoleValue
truncateConsoleMessage
createTruncationLine

Then tests can cover formatting rules.

The worker can remain responsible for executing user code.

This keeps boundaries clean.

Manual QA Script

Keep a script with snippets:

normal logs
150-line loop
6000-character string
runtime error
infinite loop
valid TypeScript with large output
copy after truncation
clear console
dark mode
mobile layout

Manual scripts should be short enough to run after UI changes.

They should not be vague checklists.

Use exact code snippets.

Test Command Roadmap

Current:

npm run test
npm run typecheck
npm run build

Future:

npm run test:unit
npm run test:e2e
npm run test:a11y

Do not add commands before they have meaningful coverage.

Test scripts should earn their place.

CI Consideration

When GitHub Actions or Vercel checks are added, start with:

npm ci
npm run test
npm run typecheck
npm run build

This gives basic confidence.

Browser tests can be added later when the practice ground has more persistent state.

Common Mistakes

• Trying to unit test the entire worker from Node.
• Not testing copy behavior after truncation.
• Ignoring timeout recovery.
• Forgetting TypeScript uses the same runtime console.
• Adding flaky browser tests too early.
• Leaving manual QA undocumented.

Final Mental Model

Console cap testing should separate:

pure formatting
worker behavior
browser recovery
visual readability
copy consistency

That keeps confidence high without making tests brittle.