Q429: Implementation Drill Transform Tests Before Snippets

What Interviewers Want To Evaluate

This drill tests whether you can choose test infrastructure before persistence when persistence depends on editor correctness.

Saved snippets will store user code.

If editor transforms are unstable, snippets will preserve confusing or damaged code.

That is why transform tests are still a high-priority pending point.

Short Interview Answer

Before shipping saved snippets, I would add focused tests for the editor transform utilities.

The utilities are pure, so tests can cover input text, selection start, selection end, output text, and output selection.

This gives confidence that Tab, Shift Tab, and Alt Down do not corrupt code before snippets begin preserving user work.

Why Tests Before Snippets

Saved snippets increase trust requirements.

Users expect:

save keeps their code
load restores their code
editing after load behaves correctly
shortcuts do not damage saved examples

If shortcut behavior is wrong, snippets make the mistake more durable.

Testing the editor core first is cheaper than debugging persistence symptoms later.

Test Targets

Test:

indentSelection
outdentSelection
duplicateLineOrSelection

Each function should be treated as:

text + selection in
text + selection out

No DOM is needed for these tests.

That makes them fast and stable.

Useful Cases

Indent:

empty file
single line
multi-line block
partial-line selection
cursor at beginning
cursor at end

Outdent:

two-space indentation
tab indentation
mixed selected lines
line with no indentation
blank line
selection starts after removed spaces

Duplicate:

current line
first line
last line
selected block
block with blank lines
selection after duplicate

These cases protect the real shortcuts.

Test File Placement

Use a simple placement:

src/lib/editorTransforms.test.ts

If the project does not yet have a test runner, create the smallest sensible setup or add a lightweight script only when it is worth the dependency.

Do not add heavy test infrastructure only to prove three pure functions.

The first step can be a small Node-based assertion script if that matches the repo better.

CI Consideration

Long term, tests should run with:

npm run test
npm run typecheck
npm run build

Right now the project already uses typecheck and build.

Adding a focused test script should not slow the workflow too much.

It should increase confidence with low cost.

Review Criteria

A reviewer should ask:

do tests cover selection ranges
do tests cover multi-line behavior
do tests cover boundaries
are utilities still pure
does the component remain simple
does the test command fit the project

If the tests only assert text output, they are incomplete.

Selection behavior is the point.

Common Mistakes

• Adding saved snippets before testing editor transforms.
• Testing only the component and ignoring pure utilities.
• Forgetting cursor positions.
• Adding a huge test framework without need.
• Treating duplicate-line behavior as copy-to-clipboard behavior.
• Not documenting how to run tests.

Final Mental Model

Transform tests are a small investment in:

editor trust
snippet safety
keyboard confidence
future refactors
review speed

They are the right foundation before persistence grows.