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

Тестирование JavaScript-кода

Профессиональный тест о модульных проверках, подменах, асинхронных сценариях и границах покрытия. Задания требуют выбирать наблюдаемое поведение, управлять временем и Promise, не подменять предмет теста целиком и разбирать нестабильность по причине.

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

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 30 вопросов и 85 минут; код лучше читать построчно, не полагаясь на первое впечатление. После завершения откроются общий процент, 6 тематических шкал и объяснение каждого решения.

Вопрос 1 из 30

Что проверяет этот тест лучше всего?

it("суммирует цены", () => {
  expect(total([{ price: 2 }, { price: 3 }])).toBe(5);
});

Порядок свойств объекта Наблюдаемый итог расчёта для конкретного набора Скорость сети Приватное имя переменной Внутреннее число вызовов reduce

Вопрос 2 из 30

Какой граничный случай особенно нужен для average?

function average(values) {
  return values.reduce((a,b)=>a+b,0) / values.length;
}

Длинное имя функции Пустой массив и явный контракт результата/ошибки Повтор запуска без входа Массив из двух обычных чисел Только 1,2,3

Вопрос 3 из 30

Зачем table-driven test для нескольких форматов?

it.each([
  ["  A ", "a"],
  ["Ёж", "ёж"],
  ["", ""],
])("нормализует %p", (input, expected) => {
  expect(normalize(input)).toBe(expected);
});

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

Вопрос 4 из 30

Почему тест приватной функции через rewire хрупок?

Публичный API нельзя надёжно проверить без доступа к private-функции Rewire изменяет скорость функции и поэтому искажает результат Наличие приватной функции само по себе означает ошибку архитектуры Тест привязан к внутреннему разбиению, которое можно менять без смены поведения Такой способ не позволяет выполнить assertions над возвращаемым значением

Вопрос 5 из 30

Что даёт property-based проверка encode/decode?

Формальную гарантию отсутствия любых ошибок во всех возможных входах Один большой snapshot результата для заранее выбранного значения Много сгенерированных входов и минимизацию контрпримера свойства Измерение времени выполнения encode и decode на одном примере Проверку отображения CSS для нескольких случайных размеров экрана

Вопрос 6 из 30

Что подменять в тесте calculateInvoice?

const rates = { get: () => 1.2 };
expect(calculateInvoice(order, rates)).toEqual(expected);

Все арифметические операторы Объект ожидаемого результата Шлюз курса валют/времени, оставляя расчёт настоящим Саму calculateInvoice Assertion library

Вопрос 7 из 30

Почему утверждение «logger.info вызван ровно один раз» может быть слишком хрупким?

expect(logger.info).toHaveBeenCalledTimes(1);

Spy не способен надёжно считать несколько последовательных вызовов Число логов может быть деталью, если важен сам предметный сигнал Метод info всегда выполняется асинхронно и меняет порядок теста Logger технически нельзя заменить тестовой реализацией Ровно один вызов logger запрещён соглашениями большинства фреймворков

Вопрос 8 из 30

Как избежать протекания spy на Date.now между тестами?

const spy = vi.spyOn(Date, "now").mockReturnValue(1000);
// afterEach: vi.restoreAllMocks()

Оставлять spy установленным, чтобы остальные тесты использовали то же время Менять timezone процесса после каждого вызова подменённого метода Удалять глобальный объект Date после каждого проверяемого сценария Восстанавливать mock в afterEach/finally или применять scoped API Перезапускать операционную систему между отдельными тестами

Вопрос 9 из 30

Чем stub отличается от spy в типичном использовании?

Stub задаёт ответ, а spy наблюдает вызовы; инструменты могут совмещать роли Spy всегда выбрасывает исключение, а stub всегда возвращает значение Stub и spy различаются способом создания: первый заменяет функцию, второй оборачивает её без изменения поведения Stub применяется исключительно к HTTP-запросам и сетевым клиентам Spy фиксирует аргументы и результат, но не позволяет задать поведение зависимости

Вопрос 10 из 30

Почему глубокий mock всего SDK опасен?

Большой mock автоматически повышает meaningful coverage продукта Методы mock-объекта не способны возвращать Promise SDK нельзя импортировать в модульных тестах JavaScript вообще Он может имитировать несуществующий контракт и пропустить несовместимость SDK Глубокий mock выполняется быстрее реальной библиотеки и меняет тайминги

Вопрос 11 из 30

Почему тест ложно проходит?

it("загружает", () => {
  load().then(value => expect(value).toBe(42));
});

Матчер expect нельзя вызывать внутри callback метода then Функция done вызывается дважды до завершения Promise fetch работает синхронно, а callback then не попадает в очередь Тест не возвращает и не ждёт Promise, поэтому assertion выполняется поздно Любой отклонённый Promise автоматически падает внутри завершённого теста

Вопрос 12 из 30

Как правильно проверить, что save(invalid) отклоняет Promise с ошибкой «denied»?

// Нужно проверить, что save(invalid)
// отклоняет Promise с ошибкой "denied".

setTimeout(()=>expect(true),0) try { await task(); } catch {} без assertion expect(task()).toThrow() await expect(save(invalid)).rejects.toThrow("denied") Не await task

Вопрос 13 из 30

Как детерминированно проверить, что второй запрос отменяет первый?

const first = deferred();
transport.mockReturnValueOnce(first.promise).mockResolvedValueOnce(newData);
const a = search("a");
const b = search("ab");

Управлять двумя Promise и сигналами, проверяя отмену и второй результат Использовать реальную сеть и фиксированный sleep между запросами Отключить AbortController и сравнить только итоговый интерфейс Увеличить общий timeout, не управляя порядком завершения запросов Повторить тест много раз и считать редкий зелёный запуск достаточным

Вопрос 14 из 30

Почему fake timers не всегда автоматически выполняют Promise.then?

vi.useFakeTimers();
const promise = Promise.resolve().then(onDone);
vi.runAllTimers();
await promise;

Таймеры и микрозадачи различны; после времени надо дождаться Promise Promise недопустим внутри теста с виртуальными таймерами Fake timers удаляют созданные Promise из очереди выполнения await автоматически меняет timezone тестовой среды Callback then всегда использует отдельную реальную секунду ожидания

Вопрос 15 из 30

Как проверить timeout без ожидания реальных пяти секунд?

vi.useFakeTimers();
const promise = requestWithTimeout();
await vi.advanceTimersByTimeAsync(5000);
await expect(promise).rejects.toMatchObject({ name: "AbortError" });

Установить timeout теста длиннее пяти секунд и ждать реального времени Запускать такой сценарий только локально, исключив его из CI Продвинуть fake clock и проверить ожидаемую отмену или ошибку Изменить production timeout на миллисекунду ради быстрого теста Подменить итоговое исключение, не выполняя логику тайм-аута

Вопрос 16 из 30

Что означает 100% statement coverage?

В проекте отсутствует код, который никогда не вызывается Все поддерживаемые браузеры выполнили хотя бы один тест Каждое пользовательское требование имеет отдельный тест Проверяемый код не содержит мутаций объектов и внешних эффектов Каждая инструкция выполнялась, но ветви и assertions могут быть слабыми

Вопрос 17 из 30

Почему этот тест может покрыть ветви, но ничего не доказать?

it("covers", () => {
  try { validate(input); } catch {}
});

Функция не вызвана Нет содержательного assertion результата или эффекта Input слишком короткий Coverage не считает if Try/catch запрещён

Вопрос 18 из 30

Что показывает mutation testing?

// Мутант: if (age >= 18) вместо if (age > 18)

Скорость сетевого соединения при выполнении интеграционных сценариев Только число синтаксических ошибок, найденных тестовым раннером Способны ли тесты заметить небольшие искусственные изменения поведения Количество import в модулях, попавших в покрытие Изменение размера клиентской сборки после запуска тестов

Вопрос 19 из 30

Нужно ли тестировать простой getter только ради процента?

Coverage технически запрещает исключать строки и файлы Getter без вычислений можно исключить из покрытия, потому что инструменты не учитывают такие строки Да, любой getter надо тестировать отдельно ради ста процентов Getter стоит проверять снимком объекта, чтобы покрыть одновременно все его свойства Не обязательно: приоритет задают риск и значимое поведение

Вопрос 20 из 30

Почему branch coverage полезен для a && b?

Он показывает оба исхода короткого замыкания, скрытые statement coverage Branch coverage полностью заменяет предметные assertions При подсчёте ветвей автоматически запускается linter проекта Он измеряет среднюю длину строк в каждом условном выражении Показатель проверяет типы операндов a и b во время сборки

Вопрос 21 из 30

Почему этот тест падает на границе Нового года в часовом поясе UTC+3?

const now = new Date("2026-12-31T21:30:00Z");
const localKey = new Intl.DateTimeFormat("sv-SE", {
  timeZone: "Europe/Moscow"
}).format(now);
const utcKey = now.toISOString().slice(0, 10);
expect(localKey).toBe(utcKey);

Тестовый раннер автоматически увеличивает год первого января Mock fetch изменяет системный часовой пояс процесса Первого января исходный массив становится пустым после сериализации Срок действия отчёта coverage заканчивается в начале календарного года Одна сторона формирует календарную дату в UTC+3, а другая — в UTC

Вопрос 22 из 30

Как найти зависимость от порядка тестов?

Всегда запускать файл в одном и том же порядке, скрывая зависимость Увеличить число workers, чтобы порядок стал менее предсказуемым Удалить afterEach, чтобы подмены сохранялись между тестами Запускать отдельно и перемешанно, ища общее состояние и ресурсы Добавить автоматический retry к каждому падающему сценарию

Вопрос 23 из 30

Почему случайный seed нужно сохранять?

const rng = createRandom(seed);
const input = generateCase(rng);

Фиксированный seed уменьшает количество вычислений процессора Он позволяет повторить конкретную последовательность, вызвавшую сбой Seed полностью заменяет входные данные найденного контрпримера Seed сохраняют, чтобы следующий запуск обязательно был зелёным Генератор случайных данных без seed запрещён тестовыми библиотеками

Вопрос 24 из 30

Что делать с flaky тестом прежде, чем добавить retry?

Удалить assertion, который иногда замечает отклонение результата Помечать неудачный запуск passed после нескольких попыток Собрать различия времени, порядка, ресурсов, сети и seed и взять их под контроль Увеличить sleep, не устанавливая точного условия готовности Ничего не исследовать: retry исправляет нестабильность приложения

Вопрос 25 из 30

Почему snapshot изменился на сотни строк после одного поля?

Большой snapshot шумен; лучше предметные проверки или меньший снимок Большой снимок полезнее точечных проверок, потому что замечает больше внутренних полей Автоматически принять обновление, поскольку изменилось только одно поле Порядок ключей в снимке меняется при добавлении поля, поэтому переписывается весь блок Отдельное поле объекта невозможно проверить без снимка всего ответа

Вопрос 26 из 30

Почему реальная БД в каждом unit test замедляет и делает набор хрупким?

beforeEach(async () => {
  await resetDatabase();
  await seedLargeFixture();
});

Coverage не учитывает строки, которые обращаются к внешней базе Более быстрый mock автоматически точнее реальной интеграции I/O и очистка доминируют; ядро тестируют локально, интеграцию отдельно SQL-запросы всегда возвращают строки в случайном порядке Использование базы данных внутри тестов запрещено стандартом JavaScript

Вопрос 27 из 30

Когда параллельные тесты конфликтуют?

const PORT = 3000;
beforeAll(() => server.listen(PORT));

Когда тесты читают разные неизменяемые const без внешних эффектов beforeEach изолирует общие ресурсы даже при параллельном выполнении Когда тесты имеют разные названия, но одинаковое число assertions Когда они делят порт, файл, схему БД или глобальный mock Конфликты возможны только в браузерных тестах, но не в Node.js

Вопрос 28 из 30

Как ускорить медленный тест с sleep(1000)?

await sleep(1000);
expect(job.status).toBe("done");

Заменить секунду случайной задержкой в несколько миллисекунд Ждать управляемое событие или продвигать clock до точного условия Перенести сценарий на ночной запуск, сохранив секундную задержку Повысить общий timeout и оставить реальное ожидание без условия Удалить assertion, чтобы тест завершался сразу после sleep

Вопрос 29 из 30

Почему огромная общая fixture ухудшает сопровождение?

Главная проблема — дополнительное место тестовых данных на диске beforeEach запрещает использовать объекты с большим числом полей Неясны значимые данные, а изменение fixture ломает чужие сценарии Большая fixture всегда работает медленнее production-данных Fixture не поддерживает вложенные объекты и массивы

Вопрос 30 из 30

Как выбрать E2E-сценарии?

Проверить ключевые пользовательские пути и наиболее опасные интеграции Повторить через интерфейс все перестановки значений каждого поля Полностью отказаться от E2E, оставив только модульные проверки Повторить через интерфейс критические ветви, уже подробно проверенные модульными тестами Открыть главную страницу без assertions и считать это smoke-тестом

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

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

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

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