Локальное хранение данных — бесплатный тест онлайн

Вопрос 1 из 25

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

Future<void> writeAtomically(File target, List<int> bytes) async {
  final temp = File('${target.path}.tmp');
  await temp.writeAsBytes(bytes, flush: true);
  await temp.rename(target.path);
}

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

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

Вопрос 2 из 25

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

Future<void> writeAtomically(File target, List<int> bytes) async {
  final temp = File('${target.path}.tmp');
  await temp.writeAsBytes(bytes, flush: true);
  await temp.rename(target.path);
}

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

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

Вопрос 3 из 25

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

Future<void> writeAtomically(File target, List<int> bytes) async {
  final temp = File('${target.path}.tmp');
  await temp.writeAsBytes(bytes, flush: true);
  await temp.rename(target.path);
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

Future<void> saveThemeMode(SharedPreferences prefs, ThemeMode mode) async {
  await prefs.setString('theme_mode', mode.name);
}

ThemeMode readThemeMode(SharedPreferences prefs) {
  return ThemeMode.values.byName(prefs.getString('theme_mode') ?? 'system');
}

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

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

Вопрос 7 из 25

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

Future<void> saveThemeMode(SharedPreferences prefs, ThemeMode mode) async {
  await prefs.setString('theme_mode', mode.name);
}

ThemeMode readThemeMode(SharedPreferences prefs) {
  return ThemeMode.values.byName(prefs.getString('theme_mode') ?? 'system');
}

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

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

Вопрос 8 из 25

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

Future<void> saveThemeMode(SharedPreferences prefs, ThemeMode mode) async {
  await prefs.setString('theme_mode', mode.name);
}

ThemeMode readThemeMode(SharedPreferences prefs) {
  return ThemeMode.values.byName(prefs.getString('theme_mode') ?? 'system');
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

Future<List<Note>> recentNotes(Database db) async {
  final rows = await db.query(
    'notes',
    where: 'archived = ?',
    whereArgs: [0],
    orderBy: 'updated_at DESC',
    limit: 50,
  );
  return rows.map(Note.fromRow).toList(growable: false);
}

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

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

Вопрос 12 из 25

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

Future<List<Note>> recentNotes(Database db) async {
  final rows = await db.query(
    'notes',
    where: 'archived = ?',
    whereArgs: [0],
    orderBy: 'updated_at DESC',
    limit: 50,
  );
  return rows.map(Note.fromRow).toList(growable: false);
}

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

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

Вопрос 13 из 25

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

Future<List<Note>> recentNotes(Database db) async {
  final rows = await db.query(
    'notes',
    where: 'archived = ?',
    whereArgs: [0],
    orderBy: 'updated_at DESC',
    limit: 50,
  );
  return rows.map(Note.fromRow).toList(growable: false);
}

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

Как проверить тему «Локальная база SQLite» через публичный результат, не цепляясь за устройство реализации?

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

Вопрос 16 из 25

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

Future<void> migrate(Database db, int oldVersion) async {
  await db.transaction((txn) async {
    if (oldVersion < 2) {
      await txn.execute('ALTER TABLE notes ADD COLUMN archived INTEGER NOT NULL DEFAULT 0');
    }
    if (oldVersion < 3) {
      await txn.execute('CREATE INDEX notes_updated_idx ON notes(updated_at)');
    }
  });
}

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

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

Вопрос 17 из 25

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

Future<void> migrate(Database db, int oldVersion) async {
  await db.transaction((txn) async {
    if (oldVersion < 2) {
      await txn.execute('ALTER TABLE notes ADD COLUMN archived INTEGER NOT NULL DEFAULT 0');
    }
    if (oldVersion < 3) {
      await txn.execute('CREATE INDEX notes_updated_idx ON notes(updated_at)');
    }
  });
}

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

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

Вопрос 18 из 25

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

Future<void> migrate(Database db, int oldVersion) async {
  await db.transaction((txn) async {
    if (oldVersion < 2) {
      await txn.execute('ALTER TABLE notes ADD COLUMN archived INTEGER NOT NULL DEFAULT 0');
    }
    if (oldVersion < 3) {
      await txn.execute('CREATE INDEX notes_updated_idx ON notes(updated_at)');
    }
  });
}

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

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

Вопрос 19 из 25

Какой тест действительно поймает возврат дефекта в теме «Миграции схемы»?

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

abstract interface class SettingsStore {
  Future<String?> read(String key);
  Future<void> write(String key, String value);
}

abstract interface class DocumentStore {
  Future<List<Document>> search(DocumentQuery query);
  Future<void> transaction(Future<void> Function(DocumentTxn) action);
}

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

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

Вопрос 22 из 25

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

abstract interface class SettingsStore {
  Future<String?> read(String key);
  Future<void> write(String key, String value);
}

abstract interface class DocumentStore {
  Future<List<Document>> search(DocumentQuery query);
  Future<void> transaction(Future<void> Function(DocumentTxn) action);
}

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

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

Вопрос 23 из 25

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

abstract interface class SettingsStore {
  Future<String?> read(String key);
  Future<void> write(String key, String value);
}

abstract interface class DocumentStore {
  Future<List<Document>> search(DocumentQuery query);
  Future<void> transaction(Future<void> Function(DocumentTxn) action);
}

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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