Потоки Stream — бесплатный тест онлайн

Вопрос 1 из 20

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

Future<void> main() async {
  final stream = Stream<int>.fromIterable([1, 2, 3]);
  final total = await stream.fold<int>(0, (a, b) => a + b);
  print(total);
}

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

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

Вопрос 2 из 20

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

Future<void> main() async {
  final stream = Stream<int>.fromIterable([1, 2, 3]);
  final total = await stream.fold<int>(0, (a, b) => a + b);
  print(total);
}

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

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

Вопрос 3 из 20

Что здесь следует считать правилом «Подписка», а что — лишь деталью текущей реализации?

Future<void> main() async {
  final stream = Stream<int>.fromIterable([1, 2, 3]);
  final total = await stream.fold<int>(0, (a, b) => a + b);
  print(total);
}

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

Какая регрессия для «Подписка» будет падать на старом дефекте и не ломаться от безопасной перестройки кода?

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

Вопрос 6 из 20

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

Stream<String> labels(Stream<int> input) {
  return input.where((n) => n.isEven).map((n) => 'item:$n');
}

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

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

Вопрос 7 из 20

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

Stream<String> labels(Stream<int> input) {
  return input.where((n) => n.isEven).map((n) => 'item:$n');
}

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

Для «Преобразование событий» всегда заменять явную ошибку нейтральным значением: `null`, пустой коллекцией или нулём. Случай «отмена во время преобразования» объявить внутренней деталью «Преобразование событий», даже если клиент видит иной результат. Спорный результат «Преобразование событий» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Операторы `map`, `where`, `asyncMap`, `transform` создают новый поток и сохраняют ленивую обработку; исключение в преобразовании становится событием ошибки. Порядок внутренних вызовов «Преобразование событий» считать публичной гарантией, которую нельзя менять при рефакторинге.

Вопрос 8 из 20

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

Stream<String> labels(Stream<int> input) {
  return input.where((n) => n.isEven).map((n) => 'item:$n');
}

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

final controller = StreamController<int>.broadcast();
final first = controller.stream.listen(print);
controller.add(1);
final second = controller.stream.listen((v) => print('late:$v'));
controller.add(2);

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

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

Вопрос 12 из 20

На ревью просят не размножать проверки по вызывающему коду. Какое исправление для «Broadcast-потоки» отвечает этому требованию?

final controller = StreamController<int>.broadcast();
final first = controller.stream.listen(print);
controller.add(1);
final second = controller.stream.listen((v) => print('late:$v'));
controller.add(2);

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

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

Вопрос 13 из 20

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

final controller = StreamController<int>.broadcast();
final first = controller.stream.listen(print);
controller.add(1);
final second = controller.stream.listen((v) => print('late:$v'));
controller.add(2);

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

Какое утверждение о показанном фрагменте и теме «Отмена подписки» опирается на реальную гарантию Dart или используемого интерфейса?

class Presenter {
  StreamSubscription<int>? _sub;
  void bind(Stream<int> source) {
    _sub = source.listen(render, onError: showError);
  }
  Future<void> dispose() async => _sub?.cancel();
}

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

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

Вопрос 17 из 20

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

class Presenter {
  StreamSubscription<int>? _sub;
  void bind(Stream<int> source) {
    _sub = source.listen(render, onError: showError);
  }
  Future<void> dispose() async => _sub?.cancel();
}

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

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

Вопрос 18 из 20

На ревью просят не размножать проверки по вызывающему коду. Какое исправление для «Отмена подписки» отвечает этому требованию?

class Presenter {
  StreamSubscription<int>? _sub;
  void bind(Stream<int> source) {
    _sub = source.listen(render, onError: showError);
  }
  Future<void> dispose() async => _sub?.cancel();
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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