TS TypeScript · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Исчерпывающая проверка вариантов

Профессиональный тест по теме «Исчерпывающая проверка вариантов»: сложные фрагменты кода, архитектурные компромиссы, диагностика и надёжность. Вопросы требуют читать код, сопоставлять статические гарантии с поведением JavaScript и выбирать решение, которое не рассыплется при развитии проекта.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. Код читайте построчно: часть заданий проверяет не результат JavaScript, а то, что TypeScript способен доказать до запуска.

Вопрос 1 из 30

Какое поле делает объединение удобным для безопасного сужения?

type Result =
  | { kind: "ok"; value: string }
  | { kind: "error"; message: string };

Любое поле типа string Совпадающее число свойств Имя псевдонима Result Обязательное поле kind с разными литералами Порядок вариантов в union

Вопрос 2 из 30

Почему payload доступен только в одной ветви?

type Event =
  | { type: "data"; payload: Uint8Array }
  | { type: "close"; code: number };

function handle(event: Event) {
  if (event.type === "data") {
    event.payload;
  }
}

Uint8Array доступен у любого объекта if добавляет отсутствующее поле TypeScript выполнил объект во время компиляции Свойство payload стало optional Проверка литерального дискриминанта сузила Event до варианта data

Вопрос 3 из 30

Какой недостаток у модели с независимыми optional-полями?

type State = {
  status: "idle" | "loaded" | "failed";
  data?: string[];
  error?: Error;
};

Optional-поля нельзя использовать с литералами Модель требует класса вместо объекта Она допускает противоречивые сочетания status автоматически становится boolean Error нельзя хранить в типе

Вопрос 4 из 30

Когда boolean-флаг хуже размеченного объединения?

Когда флаг называется enabled Когда используется const Когда значение приходит из функции Когда объект хранится локально Когда состояния требуют разных обязательных данных

Вопрос 5 из 30

Какой дискриминант выбрать для публичного протокола?

Случайное число при каждом запуске Стабильное литеральное поле с доменным смыслом Наличие любого необязательного свойства Количество ключей объекта constructor.name

Вопрос 6 из 30

Зачем функция assertNever принимает never?

function assertNever(value: never): never {
  throw new Error(`Unexpected: ${String(value)}`);
}

Чтобы ускорить switch Чтобы преобразовать любое значение в исключение Чтобы запретить throw Чтобы never появился во время выполнения Чтобы остаточный вариант не принимался как never

Вопрос 7 из 30

Почему присваивание check: never не проходит?

type Mode = "read" | "write";
function run(mode: Mode) {
  if (mode === "read") return;
  const check: never = mode;
}

Строковые литералы не сужаются Mode расширился до string После исключения read остаётся вариант write never нельзя объявлять через const return отключает анализ потока

Вопрос 8 из 30

Какой тип у x после бесконечного цикла или безусловного throw в ветви?

function fail(message: string): never { throw new Error(message); }
const x = Math.random() > 0.5 ? "ok" : fail("bad");

never unknown string | never string void

Вопрос 9 из 30

Почему never полезен не только в assertNever?

Он описывает невозможные состояния и ветви без возврата Он существует как отдельное значение JavaScript Он заменяет null Он хранит пустой объект Он означает любой тип

Вопрос 10 из 30

Что означает функция с возвращаемым типом never?

Она может вернуть любое значение Она всегда возвращает undefined Её результат следует игнорировать Она не имеет нормального пути возврата Она вызывается только компилятором

Вопрос 11 из 30

Как сделать switch исчерпывающим?

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; side: number };

function area(shape: Shape): number {
  switch (shape.kind) {
    case "circle": return Math.PI * shape.radius ** 2;
    case "square": return shape.side ** 2;
    default: return assertNever(shape);
  }
}

Вернуть 0 в default Привести shape к any Убрать возвращаемый тип default: assertNever(shape) Сравнивать только наличие radius

Вопрос 12 из 30

Почему default: throw new Error() без параметра слабее assertNever(shape)?

default:
  throw new Error("unknown shape");

Он не проверяет остаточный тип через never throw запрещён внутри switch Error всегда имеет тип any default выполняется для каждого case Он меняет Shape на unknown

Вопрос 13 из 30

Как избежать default и всё же заметить пропущенный вариант в функции, возвращающей string?

function label(state: State): string {
  switch (state.kind) {
    case "idle": return "Ожидание";
    case "ready": return "Готово";
  }
}

Добавить return '' после switch Аннотировать state как object Использовать break вместо return Явный string и noImplicitReturns поймают пропуск Отключить strictNullChecks

Вопрос 14 из 30

Когда таблица обработчиков лучше длинного switch?

Когда варианты отображаются в однотипные функции Когда ключи приходят как произвольная string Когда важно скрыть пропущенные варианты Когда нужен fallthrough Когда обработчики имеют совершенно разные сигнатуры без общей модели

Вопрос 15 из 30

Как проверить исчерпывающий switch в обзорe кода?

Добавить вариант и ожидать ошибку компиляции Запустить форматтер Проверить только default Посчитать case вручную один раз Удалить дискриминант

Вопрос 16 из 30

Что произойдёт после добавления pending?

type Status =
  | { kind: "ok"; value: string }
  | { kind: "error"; message: string }
  | { kind: "pending" };

function render(status: Status): string {
  switch (status.kind) {
    case "ok": return status.value;
    case "error": return status.message;
    default: return assertNever(status);
  }
}

pending автоматически попадёт в case ok Union удалит старый вариант error Функция вернёт пустую строку Изменение заметит только runtime pending нельзя передать параметру never

Вопрос 17 из 30

Почему catch-all вариант { kind: string } разрушает сужение?

type Event =
  | { kind: "created"; id: string }
  | { kind: string; payload: unknown };

payload автоматически становится any Литеральные строки запрещены рядом со string Широкий string также включает created Union не может содержать две структуры created исчезает во время выполнения

Вопрос 18 из 30

Как сохранить обратную совместимость при новом необязательном поле, не создавая новый вариант?

type Created = { kind: "created"; id: string; source?: "api" | "import" };

Делать поле optional лишь при ясной семантике отсутствия Удалить дискриминант kind Заменить весь тип на Record<string, unknown> Всегда добавлять обязательное поле без версии Скрыть изменение через any

Вопрос 19 из 30

Закрытый union публикуется как API. Что считать потенциально несовместимым изменением?

Переименование локальной переменной Исправление описания типа Добавление внутреннего helper Добавление варианта в ранее закрытый набор Ускорение реализации без изменения контракта

Вопрос 20 из 30

Как проектировать протокол, где сервер может присылать новые неизвестные виды событий?

Отделить известные варианты от проверяемого UnknownEvent Добавить default, который молча считает событие успешным Использовать enum и не валидировать строки Считать типы сервера неизменными Утверждать любой ответ как известный union

Вопрос 21 из 30

Что должен подтвердить типовой тест функции assertNever?

function assertNever(value: never): never {
  throw new Error(`Unexpected: ${String(value)}`);
}

Она принимает любой object и бросает исключение Она проверяет строковый discriminant во время выполнения Она превращает неизвестный вариант в null Она удаляет default-ветку из JavaScript Необработанный вариант не совместим с параметром never

Вопрос 22 из 30

Какой отрицательный пример лучше проверяет исчерпывающий switch?

type Shape =
 | { kind: "circle"; radius: number }
 | { kind: "square"; side: number }
 | { kind: "triangle"; base: number; height: number };

Привести shape к never через as Добавить default, возвращающий 0 Добавить triangle и ждать ошибку в assertNever Вызвать area для circle Проверить только runtime-исключение на старых вариантах

Вопрос 23 из 30

Почему даже исчерпывающий switch не защищает от произвольного JSON?

declare const raw: unknown;
// raw получен из JSON.parse(body)

Сначала проверить внешний kind в runtime JSON.parse удаляет discriminant TypeScript выполняет assertNever при компиляции Union принимает только данные, созданные в том же файле switch автоматически меняет JSON Schema

Вопрос 24 из 30

После рефакторинга в switch появился общий default, возвращающий заглушку. Какой тест обнаружит потерю исчерпываемости?

Только runtime-тест старых вариантов Проверка числа case-веток регулярным выражением Добавить вариант модели и ожидать ошибку обработчика Снимок текста функции Приведение аргумента default к never

Вопрос 25 из 30

Какой набор проверок нужен для функции, обрабатывающей Result union?

Runtime-тесты вариантов плюс compile-time исчерпываемость Только assertNever без обычных тестов Только snapshot текста ошибки Только проверку свойства kind Только один успешный вариант

Вопрос 26 из 30

Какой публичный тип ошибки проще расширять контролируемо?

export type LoadError =
 | { kind: "not_found"; id: UserId }
 | { kind: "forbidden" }
 | { kind: "temporary"; retryAfterMs: number };

unknown, который каждый потребитель приводит самостоятельно Размеченный union с устойчивым kind Строка, составленная из кода и текста Один Error с произвольным message object без обязательных свойств

Вопрос 27 из 30

Что в этой модели является лишней утечкой внутреннего протокола?

export type PublicFailure = {
  kind: "temporary";
  retryAfterMs: number;
  internalStateCode: 17 | 23 | 41;
};

Идентификатор запроса для журнала Публичный kind "temporary" Поле retryAfterMs Поле internalStateCode с кодом драйвера Readonly-модификатор результата

Вопрос 28 из 30

Сервер может прислать новый kind, которого старая версия клиента не знает. Какой подход устойчивее?

type KnownEvent =
 | { kind: "created"; id: string }
 | { kind: "deleted"; id: string };

Сразу приводить ответ к известному union через as Валидировать протокол и обрабатывать unknown_variant Полагаться на assertNever для непроверенного JSON Считать любой неизвестный kind успешным Удалять поле kind перед обработкой

Вопрос 29 из 30

Как проверить совместимость добавления нового варианта публичного union?

Сравнить размер JavaScript Переименовать discriminant без тестов Проверить только новый case внутри библиотеки Запустить formatter Прогнать старые consumer-примеры исчерпывающей обработки

Вопрос 30 из 30

Какой признак говорит, что union-модель стала слишком трудной для сопровождения?

Есть функция assertNever Discriminant имеет строковый литеральный тип kind больше не определяет допустимые данные варианта Для результата используется switch В модели больше двух вариантов

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу