HTTP-клиент и работа с API — бесплатный тест онлайн

Вопрос 1 из 25

Какой вывод о фрагменте «Запросы» останется верным после безопасного рефакторинга?

Future<Response> loadOrder(String rawId) {
  final uri = baseUri.replace(
    pathSegments: [...baseUri.pathSegments, 'orders', rawId],
    queryParameters: {'include': 'items'},
  );
  return client.get(uri);
}

// Контекст задания: проверка семантики фрагмента.

Случай «ошибочный HTTP-метод» объявить внутренней деталью «Запросы», даже если клиент видит иной результат. Предполагается, что компиляция уже подтверждает весь договор «Запросы». Спорный результат «Запросы» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Для «Запросы» считать случаи «спецсимволы в сегменте пути, параметры запроса, пустое тело и ошибочный HTTP-метод» эквивалентными, если программа не завершается аварийно. HTTP-запрос должен явно задавать метод, URI, кодирование тела и ожидаемый формат ответа; повторяемые операции безопаснее проектировать идемпотентными. Порядок внутренних вызовов «Запросы» считать публичной гарантией, которую нельзя менять при рефакторинге. Клиенту «Запросы» предлагают самостоятельно уточнять смысл спорного результата.

Вопрос 2 из 25

Фрагмент выглядит убедительно на типичных данных. Какие входы по теме «Запросы» нельзя проверять одним общим ожиданием?

Future<Response> loadOrder(String rawId) {
  final uri = baseUri.replace(
    pathSegments: [...baseUri.pathSegments, 'orders', rawId],
    queryParameters: {'include': 'items'},
  );
  return client.get(uri);
}

// Контекст задания: анализ граничных входов.

Задать самостоятельные ожидания для случаев: спецсимволы в сегменте пути, параметры запроса, пустое тело и ошибочный HTTP-метод. Для «Запросы» ограничиться случаем «спецсимволы в сегменте пути», а остальные входы считать тем же классом отказа. Объединить «спецсимволы в сегменте пути» и «параметры запроса» в один тест «Запросы» с общим ожидаемым исходом. Во всех спорных входах «Запросы» проверять только отсутствие необработанного исключения, не сравнивая состояние. Проверить для «Запросы» только самый сложный случай «ошибочный HTTP-метод», считая остальные границы косвенно покрытыми.

Вопрос 3 из 25

Какое изменение показанного кода исправляет правило «Запросы», а не маскирует один его симптом?

Future<Response> loadOrder(String rawId) {
  final uri = baseUri.replace(
    pathSegments: [...baseUri.pathSegments, 'orders', rawId],
    queryParameters: {'include': 'items'},
  );
  return client.get(uri);
}

// Контекст задания: выбор места исправления.

Скопировать защиту «Запросы» во все найденные места вызова и считать повторение единым исправлением. Скрыть сбой «Запросы» автоматической повторной попыткой без ограничения числа запусков. Ответственность за особый случай «Запросы» при этом остаётся у вызывающего кода. Добавить в «Запросы» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. Оставить поведение «Запросы» прежним, но заменить сообщение об ошибке на более подробное. Изменение кажется безопасным, потому что обычный путь «Запросы» остаётся прежним. Собирать URI штатными средствами, явно задавать метод и кодировать тело в согласованном формате.

Вопрос 4 из 25

Какой сценарий должен стать постоянной проверкой после исправления «Запросы»?

Для границы «Запросы» назначить то же ожидание, что и успеху, и проверять лишь отсутствие исключения. Проверить путь со спецсимволами, несколько query-параметров, пустое тело и фактически отправленный метод. Для «Запросы» оставить только тест обычного пути, а исправленный случай считать закрытым ревью. Запускать проверку «Запросы» после выпуска на рабочем трафике, а не до изменения зависимости. Сохранить сценарий «ошибочный HTTP-метод» в ручном чек-листе «Запросы», не добавляя автоматическую проверку.

Вопрос 5 из 25

Что должно оставаться неизменным при замене реализации темы «Запросы»?

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

Вопрос 6 из 25

Локальная заплатка помогла только одному клиенту этого кода. Какая правка устраняет причину в теме «Заголовки»?

Future<Response> createOrder(OrderDraft draft) async {
  final token = await tokens.current();
  return client.post(
    baseUri.resolve('/orders'),
    headers: {
      'Authorization': 'Bearer $token',
      'Content-Type': 'application/json',
      'Accept': 'application/json',
    },
    body: jsonEncode(draft.toJson()),
  );
}

// Контекст задания: выбор места исправления.

Скопировать защиту «Заголовки» во все найденные места вызова и считать повторение единым исправлением. Добавить обработку «просроченный токен» в ближайший вызывающий метод, не меняя общий компонент «Заголовки». Ослабить правило «Заголовки» для случая «утечка авторизации при перенаправлении», чтобы спорный вход проходил как допустимый. Формировать заголовки по назначению и обновлять авторизацию на доверенной границе, не пересылая секрет на другой узел. В решении «Заголовки» перехватывать любое исключение и возвращать нейтральное значение без указания причины.

Вопрос 7 из 25

На ревью спорят, достаточно ли одного сквозного теста для «Заголовки». Какой набор действительно раскрывает границы поведения?

Future<Response> createOrder(OrderDraft draft) async {
  final token = await tokens.current();
  return client.post(
    baseUri.resolve('/orders'),
    headers: {
      'Authorization': 'Bearer $token',
      'Content-Type': 'application/json',
      'Accept': 'application/json',
    },
    body: jsonEncode(draft.toJson()),
  );
}

// Контекст задания: анализ граничных входов.

Автоматизировать обычный путь «Заголовки», а случай «утечка авторизации при перенаправлении» оставить в ручном чек-листе выпуска. Проверить независимо друг от друга: просроченный токен, отсутствие `Content-Type`, неверный `Accept` и утечка авторизации при перенаправлении. Во всех спорных входах «Заголовки» проверять только отсутствие необработанного исключения, не сравнивая состояние. Объединить «просроченный токен» и «отсутствие `Content-Type`» в один тест «Заголовки» с общим ожидаемым исходом. Проверить для «Заголовки» только самый сложный случай «утечка авторизации при перенаправлении», считая остальные границы косвенно покрытыми.

Вопрос 8 из 25

На какую гарантию языка или интерфейса можно опереться при разборе этого кода по теме «Заголовки»?

Future<Response> createOrder(OrderDraft draft) async {
  final token = await tokens.current();
  return client.post(
    baseUri.resolve('/orders'),
    headers: {
      'Authorization': 'Bearer $token',
      'Content-Type': 'application/json',
      'Accept': 'application/json',
    },
    body: jsonEncode(draft.toJson()),
  );
}

// Контекст задания: проверка семантики фрагмента.

Заголовки авторизации, типа содержимого и согласования формата имеют разные назначения; секретный токен нельзя помещать в адрес запроса или обычный журнал. Для «Заголовки» считать случаи «просроченный токен, отсутствие `Content-Type`, неверный `Accept` и утечка авторизации при перенаправлении» эквивалентными, если программа не завершается аварийно. Случай «утечка авторизации при перенаправлении» объявить внутренней деталью «Заголовки», даже если клиент видит иной результат. Порядок внутренних вызовов «Заголовки» считать публичной гарантией, которую нельзя менять при рефакторинге. Вывод делают по поведению текущей реализации «Заголовки» на обычном входе. Спорный результат «Заголовки» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.

Вопрос 9 из 25

Какой контракт по теме «Заголовки» отделяет наблюдаемое поведение от внутренних шагов?

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

Вопрос 10 из 25

Какой сценарий должен стать постоянной проверкой после исправления «Заголовки»?

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

Вопрос 11 из 25

В показанном решении проблему обходят рядом с одним вызовом. Какое изменение исправляет саму границу темы «Тайм-ауты»?

Future<Response> loadFeed() async {
  try {
    return await client
        .get(baseUri.resolve('/feed'))
        .timeout(const Duration(seconds: 8));
  } on TimeoutException {
    throw const FeedUnavailable(reason: 'timeout');
  }
}

// Контекст задания: выбор места исправления.

Ослабить правило «Тайм-ауты» для случая «работа сервера после локального тайм-аута», чтобы спорный вход проходил как допустимый. Добавить обработку «медленное соединение» в ближайший вызывающий метод, не меняя общий компонент «Тайм-ауты». Задать разумный тайм-аут и отдельно определить, как отменяется локальная работа и можно ли безопасно повторить запрос. Скопировать защиту «Тайм-ауты» во все найденные места вызова и считать повторение единым исправлением. В решении «Тайм-ауты» перехватывать любое исключение и возвращать нейтральное значение без указания причины.

Вопрос 12 из 25

Что в поведении этого кода гарантировано правилами темы «Тайм-ауты», а не случайно совпало в одном запуске?

Future<Response> loadFeed() async {
  try {
    return await client
        .get(baseUri.resolve('/feed'))
        .timeout(const Duration(seconds: 8));
  } on TimeoutException {
    throw const FeedUnavailable(reason: 'timeout');
  }
}

// Контекст задания: проверка семантики фрагмента.

Случай «работа сервера после локального тайм-аута» объявить внутренней деталью «Тайм-ауты», даже если клиент видит иной результат. Для «Тайм-ауты» считать случаи «медленное соединение, зависший ответ, отмена вызывающей стороны и работа сервера после локального тайм-аута» эквивалентными, если программа не завершается аварийно. Спорный результат «Тайм-ауты» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Различия между версиями SDK для «Тайм-ауты» в этом выводе не учитываются. Тайм-аут ограничивает ожидание, но сам по себе не гарантирует отмену работы на сервере; повтор запроса допустим только с учётом идемпотентности и бюджета попыток. Порядок внутренних вызовов «Тайм-ауты» считать публичной гарантией, которую нельзя менять при рефакторинге. Вывод делают по поведению текущей реализации «Тайм-ауты» на обычном входе.

Вопрос 13 из 25

На ревью спорят, достаточно ли одного сквозного теста для «Тайм-ауты». Какой набор действительно раскрывает границы поведения?

Future<Response> loadFeed() async {
  try {
    return await client
        .get(baseUri.resolve('/feed'))
        .timeout(const Duration(seconds: 8));
  } on TimeoutException {
    throw const FeedUnavailable(reason: 'timeout');
  }
}

// Контекст задания: анализ граничных входов.

Проверить для «Тайм-ауты» только самый сложный случай «работа сервера после локального тайм-аута», считая остальные границы косвенно покрытыми. Автоматизировать обычный путь «Тайм-ауты», а случай «работа сервера после локального тайм-аута» оставить в ручном чек-листе выпуска. Составить отдельные сценарии для границ: медленное соединение, зависший ответ, отмена вызывающей стороны и работа сервера после локального тайм-аута. Для «Тайм-ауты» ограничиться случаем «медленное соединение», а остальные входы считать тем же классом отказа. Во всех спорных входах «Тайм-ауты» проверять только отсутствие необработанного исключения, не сравнивая состояние.

Вопрос 14 из 25

Перед обновлением зависимости нужно защитить исправление «Тайм-ауты». Какая проверка подходит лучше всего?

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

Вопрос 15 из 25

Какой контракт по теме «Тайм-ауты» отделяет наблюдаемое поведение от внутренних шагов?

Перед вызовом «Тайм-ауты» заставить клиента повторять валидацию, не описывая отказ самого компонента. Для реализаций «Тайм-ауты» требовать одинакового числа обращений к зависимостям при совпадающем результате. Тайм-аут должен приводить к отличимому результату и не обещать автоматическую отмену операции на сервере. В договоре «Тайм-ауты» описать только успешный путь, оставив спорные входы на усмотрение реализации. Из «Тайм-ауты» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте.

Вопрос 16 из 25

Команда хочет сократить набор проверок для «Обработка статусов» до одного сценария. Какой вариант сохраняет важные различия?

OrderResult parseOrderResponse(Response response) {
  return switch (response.statusCode) {
    200 => OrderResult.found(Order.fromJson(jsonDecode(response.body))),
    404 => const OrderResult.notFound(),
    401 || 403 => const OrderResult.forbidden(),
    _ => OrderResult.failed(status: response.statusCode),
  };
}

// Контекст задания: анализ граничных входов.

Проверить для «Обработка статусов» только самый сложный случай «ошибочный статус с валидным телом», считая остальные границы косвенно покрытыми. Автоматизировать обычный путь «Обработка статусов», а случай «ошибочный статус с валидным телом» оставить в ручном чек-листе выпуска. Проверить входы «Обработка статусов» только на текущей реализации, не закрепляя результат как внешний договор. Не объединять в один исход следующие случаи: ответы 204, 400, 401, 404, 500, успешный статус с ошибочным JSON и ошибочный статус с валидным телом. Во всех спорных входах «Обработка статусов» проверять только отсутствие необработанного исключения, не сравнивая состояние.

Вопрос 17 из 25

В показанном решении проблему обходят рядом с одним вызовом. Какое изменение исправляет саму границу темы «Обработка статусов»?

OrderResult parseOrderResponse(Response response) {
  return switch (response.statusCode) {
    200 => OrderResult.found(Order.fromJson(jsonDecode(response.body))),
    404 => const OrderResult.notFound(),
    401 || 403 => const OrderResult.forbidden(),
    _ => OrderResult.failed(status: response.statusCode),
  };
}

// Контекст задания: выбор места исправления.

Добавить обработку «ответы 204» в ближайший вызывающий метод, не меняя общий компонент «Обработка статусов». Скрыть сбой «Обработка статусов» автоматической повторной попыткой без ограничения числа запусков. Перенести проверку «Обработка статусов» в тестовый код, не меняя производственную реализацию. Оставить поведение «Обработка статусов» прежним, но заменить сообщение об ошибке на более подробное. Сначала интерпретировать статус, затем разбирать тело по схеме конкретного результата.

Вопрос 18 из 25

Что в поведении этого кода гарантировано правилами темы «Обработка статусов», а не случайно совпало в одном запуске?

OrderResult parseOrderResponse(Response response) {
  return switch (response.statusCode) {
    200 => OrderResult.found(Order.fromJson(jsonDecode(response.body))),
    404 => const OrderResult.notFound(),
    401 || 403 => const OrderResult.forbidden(),
    _ => OrderResult.failed(status: response.statusCode),
  };
}

// Контекст задания: проверка семантики фрагмента.

Спорный результат «Обработка статусов» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Коды 2xx, 4xx и 5xx несут разный смысл; успешный JSON-парсинг не превращает ответ 500 в успех, а 204 не обязан содержать тело. Случай «ошибочный статус с валидным телом» объявить внутренней деталью «Обработка статусов», даже если клиент видит иной результат. Порядок внутренних вызовов «Обработка статусов» считать публичной гарантией, которую нельзя менять при рефакторинге. В теме «Обработка статусов» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа.

Вопрос 19 из 25

Как сформулировать публичное обещание темы «Обработка статусов», не привязывая клиента к конкретному классу?

Перед вызовом «Обработка статусов» заставить клиента повторять валидацию, не описывая отказ самого компонента. Для «Обработка статусов» закрепить порядок вызовов при «ответы 204» и потребовать одинаковых вспомогательных методов. Каждая группа статусов должна преобразовываться в свой типизированный исход, не смешивая транспортный успех с предметным. Для реализаций «Обработка статусов» требовать одинакового числа обращений к зависимостям при совпадающем результате. Считать реализации «Обработка статусов» совместимыми на обычном входе, даже если они расходятся на «ответы 204».

Вопрос 20 из 25

Перед обновлением зависимости нужно защитить исправление «Обработка статусов». Какая проверка подходит лучше всего?

Проверить 2xx без тела, основные 4xx и 5xx, неверный JSON и тело ошибки. В регрессии «Обработка статусов» сравнивать текст журналов вместо возвращаемого результата и состояния. В тесте «Обработка статусов» подменить спорный механизм готовым успешным ответом ради стабильности. Проверять «Обработка статусов» на одной текущей реализации и не фиксировать внешний договор. После операции «Обработка статусов» проверять приватные поля и точное число внутренних вызовов.

Вопрос 21 из 25

Код прошёл демонстрационный пример, но границы не разобраны. Что нужно проверить отдельно в теме «Читаемость решения»?

Future<OrderResult> loadOrder(OrderId id) async {
  final response = await transport.get('/orders/${id.value}');
  final payload = decoder.decodeObject(response.body);
  return mapper.toOrderResult(response.statusCode, payload);
}

// Контекст задания: анализ граничных входов.

Проверить для «Читаемость решения» только самый сложный случай «а также потеря контекста ошибки», считая остальные границы косвенно покрытыми. Составить отдельные сценарии для границ: смешение транспорта, декодирования и предметного решения в одном методе, а также потеря контекста ошибки. Автоматизировать обычный путь «Читаемость решения», а случай «а также потеря контекста ошибки» оставить в ручном чек-листе выпуска. Объединить «смешение транспорта» и «декодирования и предметного решения в одном методе» в один тест «Читаемость решения» с общим ожидаемым исходом. Во всех спорных входах «Читаемость решения» проверять только отсутствие необработанного исключения, не сравнивая состояние.

Вопрос 22 из 25

Какое утверждение корректно связывает показанный код с семантикой темы «Читаемость решения»?

Future<OrderResult> loadOrder(OrderId id) async {
  final response = await transport.get('/orders/${id.value}');
  final payload = decoder.decodeObject(response.body);
  return mapper.toOrderResult(response.statusCode, payload);
}

// Контекст задания: проверка семантики фрагмента.

Слой клиента должен отделять транспорт, разбор данных и предметные ошибки, чтобы вызывающий код не зависел от деталей конкретной HTTP-библиотеки. Спорный результат «Читаемость решения» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. В теме «Читаемость решения» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа. Случай «а также потеря контекста ошибки» объявить внутренней деталью «Читаемость решения», даже если клиент видит иной результат. Порядок внутренних вызовов «Читаемость решения» считать публичной гарантией, которую нельзя менять при рефакторинге.

Вопрос 23 из 25

В показанном решении проблему обходят рядом с одним вызовом. Какое изменение исправляет саму границу темы «Читаемость решения»?

Future<OrderResult> loadOrder(OrderId id) async {
  final response = await transport.get('/orders/${id.value}');
  final payload = decoder.decodeObject(response.body);
  return mapper.toOrderResult(response.statusCode, payload);
}

// Контекст задания: выбор места исправления.

Скрыть сбой «Читаемость решения» автоматической повторной попыткой без ограничения числа запусков. Перенести проверку «Читаемость решения» в тестовый код, не меняя производственную реализацию. Разделить отправку запроса, декодирование ответа и преобразование в предметный результат. Оставить поведение «Читаемость решения» прежним, но заменить сообщение об ошибке на более подробное. Скопировать защиту «Читаемость решения» во все найденные места вызова и считать повторение единым исправлением.

Вопрос 24 из 25

Ручная проверка по теме «Читаемость решения» прошла. Как превратить её в полезную автоматическую регрессию?

Для границы «Читаемость решения» назначить то же ожидание, что и успеху, и проверять лишь отсутствие исключения. Запускать проверку «Читаемость решения» после выпуска на рабочем трафике, а не до изменения зависимости. Сохранить сценарий «а также потеря контекста ошибки» в ручном чек-листе «Читаемость решения», не добавляя автоматическую проверку. Для «Читаемость решения» оставить только тест обычного пути, а исправленный случай считать закрытым ревью. Проверить каждый этап отдельно и один интеграционный сценарий, который связывает транспорт, декодирование и отображение ошибки.

Вопрос 25 из 25

Как сформулировать публичное обещание темы «Читаемость решения», не привязывая клиента к конкретному классу?

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