valkyrjaio / valkyrja-ts / 30416932613

100%

push

github

[Cli] Remove the dead empty allowed responses handling from Answer and QuestionWriter (#99)

# Description

Ports two related dead-code removals from the PHP reference
implementation. Both come from one
invariant: **an `Answer`'s allowed responses are never empty.** The
constructor appends
`defaultResponse` when it is absent, and `withAllowedResponses()` and
`withDefaultResponse()` both
re-add it, so `getAllowedResponses()` always returns at least one entry.
Two places assumed
otherwise.

**1. `Answer.isValidResponse()`** opened with a clause that can never be
`true`:

```ts
return (
    (this.allowedResponses.length === 0 && validationCallable === null) ||
    this.allowedResponses.includes(userResponse) ||
    (validationCallable !== null && validationCallable(userResponse))
);
```

**2. `QuestionWriter.writeQuestion()`** guarded rendering the
allowed-response list with
`if (validResponses.length > 0)`, which is always taken.

Java already does both of these and documents the invariant in place;
the comments added here are
worded to match `Answer.java` and `QuestionWriter.java`, so the ports
read alike.

## A test asserting the opposite semantics was removed

Unlike PHP and Java, this port had a test that reached the dead clause
by subclassing `Answer` to
force an empty list, and asserted "accept anything":

```ts
it('treats any response as valid when there are no allowed responses or validation callable', () => {
    // The public constructor always keeps the default response, so force an empty list.
    class EmptyAllowedAnswer extends Answer { … this.allowedResponses = []; }
    expect(new EmptyAllowedAnswer().withUserResponse('anything').isValidResponse()).toBe(true);
});
```

That state is unreachable through the public API — the test's own
comment says so — and the
semantics it asserted contradicts both sibling ports. The clause's
history in PHP shows it was
never meant to mean "accept anything": the same commit that added it
also added the co... (continued)

1592 of 1592 branches covered (100.0%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

3476 of 3476 relevant lines covered (100.0%)

29.15 hits per line