Взаимодействие с нативным кодом — бесплатный тест онлайн

Вопрос 1 из 30

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

const channel = MethodChannel('app.example/battery');

Future<int> batteryLevel() async {
  final value = await channel.invokeMethod<int>('level', {'protocol': 2});
  if (value == null) throw const PlatformException(code: 'empty-result');
  return value;
}

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

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

Вопрос 2 из 30

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

const channel = MethodChannel('app.example/battery');

Future<int> batteryLevel() async {
  final value = await channel.invokeMethod<int>('level', {'protocol': 2});
  if (value == null) throw const PlatformException(code: 'empty-result');
  return value;
}

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

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

Вопрос 3 из 30

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

const channel = MethodChannel('app.example/battery');

Future<int> batteryLevel() async {
  final value = await channel.invokeMethod<int>('level', {'protocol': 2});
  if (value == null) throw const PlatformException(code: 'empty-result');
  return value;
}

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

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

Вопрос 4 из 30

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

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

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

typedef NativeHash = Uint64 Function(Pointer<Uint8>, IntPtr);
typedef DartHash = int Function(Pointer<Uint8>, int);

final hash = library.lookupFunction<NativeHash, DartHash>('hash_bytes');

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

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

Вопрос 7 из 30

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

typedef NativeHash = Uint64 Function(Pointer<Uint8>, IntPtr);
typedef DartHash = int Function(Pointer<Uint8>, int);

final hash = library.lookupFunction<NativeHash, DartHash>('hash_bytes');

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

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

Вопрос 8 из 30

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

typedef NativeHash = Uint64 Function(Pointer<Uint8>, IntPtr);
typedef DartHash = int Function(Pointer<Uint8>, int);

final hash = library.lookupFunction<NativeHash, DartHash>('hash_bytes');

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

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

Вопрос 9 из 30

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

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

Вопрос 10 из 30

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

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

Вопрос 11 из 30

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

final class NativePoint extends Struct {
  @Double() external double x;
  @Double() external double y;
}

final Pointer<NativePoint> point = calloc<NativePoint>();

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

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

Вопрос 12 из 30

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

final class NativePoint extends Struct {
  @Double() external double x;
  @Double() external double y;
}

final Pointer<NativePoint> point = calloc<NativePoint>();

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

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

Вопрос 13 из 30

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

final class NativePoint extends Struct {
  @Double() external double x;
  @Double() external double y;
}

final Pointer<NativePoint> point = calloc<NativePoint>();

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

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

Вопрос 14 из 30

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

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

Вопрос 15 из 30

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

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

Вопрос 16 из 30

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

Future<LocationResult> readLocation() async {
  try {
    final raw = await channel.invokeMapMethod<String, Object?>('readLocation');
    return LocationResult.fromPlatform(raw);
  } on PlatformException catch (error) {
    return LocationResult.failed(code: error.code, message: error.message);
  }
}

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

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

Вопрос 17 из 30

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

Future<LocationResult> readLocation() async {
  try {
    final raw = await channel.invokeMapMethod<String, Object?>('readLocation');
    return LocationResult.fromPlatform(raw);
  } on PlatformException catch (error) {
    return LocationResult.failed(code: error.code, message: error.message);
  }
}

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

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

Вопрос 18 из 30

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

Future<LocationResult> readLocation() async {
  try {
    final raw = await channel.invokeMapMethod<String, Object?>('readLocation');
    return LocationResult.fromPlatform(raw);
  } on PlatformException catch (error) {
    return LocationResult.failed(code: error.code, message: error.message);
  }
}

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

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

Какое описание семантики показанного решения по теме «Проверка корректности» является точным?

test('native checksum matches reference implementation', () {
  final samples = <Uint8List>[Uint8List(0), Uint8List.fromList([0, 1, 255])];
  for (final bytes in samples) {
    expect(nativeChecksum(bytes), referenceChecksum(bytes));
  }
});

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

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

Вопрос 22 из 30

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

test('native checksum matches reference implementation', () {
  final samples = <Uint8List>[Uint8List(0), Uint8List.fromList([0, 1, 255])];
  for (final bytes in samples) {
    expect(nativeChecksum(bytes), referenceChecksum(bytes));
  }
});

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

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

Вопрос 23 из 30

Текущая защита работает лишь в одном сценарии. Что следует изменить в самом решении по теме «Проверка корректности»?

test('native checksum matches reference implementation', () {
  final samples = <Uint8List>[Uint8List(0), Uint8List.fromList([0, 1, 255])];
  for (final bytes in samples) {
    expect(nativeChecksum(bytes), referenceChecksum(bytes));
  }
});

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

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

Вопрос 24 из 30

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

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

Вопрос 25 из 30

Две реализации решают задачу «Проверка корректности» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

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

Вопрос 26 из 30

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

Future<CodecResult> decodeSafely(Uint8List bytes) async {
  if (!featureFlags.nativeCodec) return dartCodec.decode(bytes);
  try {
    return await nativeCodecProcess.decode(bytes);
  } on NativeProcessCrashed {
    featureFlags.disableNativeCodec();
    return dartCodec.decode(bytes);
  }
}

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

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

Вопрос 27 из 30

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

Future<CodecResult> decodeSafely(Uint8List bytes) async {
  if (!featureFlags.nativeCodec) return dartCodec.decode(bytes);
  try {
    return await nativeCodecProcess.decode(bytes);
  } on NativeProcessCrashed {
    featureFlags.disableNativeCodec();
    return dartCodec.decode(bytes);
  }
}

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

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

Вопрос 28 из 30

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

Future<CodecResult> decodeSafely(Uint8List bytes) async {
  if (!featureFlags.nativeCodec) return dartCodec.decode(bytes);
  try {
    return await nativeCodecProcess.decode(bytes);
  } on NativeProcessCrashed {
    featureFlags.disableNativeCodec();
    return dartCodec.decode(bytes);
  }
}

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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