Сериализация и внешние данные — бесплатный тест онлайн

Вопрос 1 из 30

В «Generated serializer модели» выбрали решение: Проверять round-trip и конкретные договорённые имена, а не хрупкое полное сравнение строки без необходимости. Какова его реальная цена?

Главный риск формулируют так: Аннотация автоматически шифрует поля перед выводом. Главная цена решения — необходимость учитывать, что декодер обязан отвергать любое изменение пробелов. Generated serializer быстрее и безопаснее reflection, но требует compiler plugin и явной поддержки нестандартных типов. Сопровождение усложнится, если окажется, что порядок свойств data class гарантирует байтово одинаковый JSON во всех версиях и настройках. После правки останется ограничение: @Serializable применяет Java Serializable и пишет бинарный ObjectStream.

Вопрос 2 из 30

Зачем заданы стабильные `@SerialName`?

// Проследите фактическое выполнение без изменения кода.
@Serializable sealed interface Event
@Serializable @SerialName("created") data class Created(val id: String): Event
@Serializable @SerialName("deleted") data class Deleted(val id: String): Event

Аннотация автоматически мигрирует старые поля подтипа. Они отделяют внешний discriminator от имён Kotlin-классов и позволяют безопасный рефакторинг. SerialName выбирает поток, в котором декодируется подтип. Они заставляют сериализатор хранить оба имени одновременно. Без них sealed-полиморфизм невозможен даже внутри одной версии процесса.

Вопрос 3 из 30

Что в семантике Kotlin или используемого API объясняет «Лишнее поле во входном JSON»?

// На ревью требуется объяснить причину поведения.
val json = Json { ignoreUnknownKeys = true }
@Serializable data class User(val id: Int)
val user = json.decodeFromString<User>("""{"id":1,"name":"Ada"}""")

Контракт здесь понимают так: IgnoreUnknownKeys игнорирует также отсутствие обязательного id. Семантика фрагмента приводит к тому, что поле name автоматически добавится в объект через reflection. Причина результата в том, что декодирование в показанном сценарии падает, потому что data class не содержит name. Поведение связывают с правилом: User.id станет null из-за присутствия лишнего ключа. Игнорирование неизвестных полей помогает forward compatibility, но не отменяет проверку обязательных известных полей и их типов.

Вопрос 4 из 30

Что следует изменить прежде всего во фрагменте «Новое поле с default»?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Serializable
data class Profile(
    val id: String,
    val nickname: String = ""
)

Зафиксировать текущее поведение регрессионным тестом: Он заставляет старые приложения понимать nickname. Добавить локальную обработку результата, потому что default применяется также к полю с неверным типом вместо ошибки. Хранить версию или явный мигратор для долговременных данных и тестировать чтение fixtures всех поддерживаемых версий. Оставить структуру прежней, документировав утверждение: Default добавляет поле в уже сохранённые файлы без их чтения. Передать ответственность владельцу вызова, предполагая, что он позволяет изменить тип id без миграции.

Вопрос 5 из 30

Что проверить отдельно, чтобы не принять «Исторические JSON fixtures» за универсальное правило?

Добавить граничный тест на утверждение: Случайный текст, для которого проверяется лишь факт любого исключения. Тесты только JVM могут не поймать отличия платформенных типов и форматов времени в многоплатформенной модели. Проверить крайний ввод, при котором один JSON, заново сгенерированный текущей версией serializer. Отдельно воспроизвести случай, в котором мок serializer, который в показанном сценарии возвращает Profile по умолчанию. Зафиксировать сценарий, где ожидается: Только snapshot отформатированной строки с фиксированным порядком полей.

Вопрос 6 из 30

Что станет новой точкой внимания после изменения «DTO на внешней границе»: Не разделять один stateful Json-конфиг между недоверенными протоколами с разными модулями типов без явной политики?

Цена упрощения проявится, если после toDomain сериализатор автоматически кэширует пользователя. DTO добавляет преобразование и типы, зато защищает домен от формата, версии и частично корректных данных. После внедрения придётся исходить из того, что dTO нужен, чтобы каждый decode запускался на отдельном потоке. Новый риск связан с тем, что userDto гарантированно immutable независимо от типов его свойств. Практическое ограничение подхода: Разделение устраняет необходимость версионировать внешний JSON.

Вопрос 7 из 30

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

// На ревью требуется объяснить причину поведения.
@Serializable sealed interface Event
@Serializable @SerialName("created") data class Created(val id: String): Event
@Serializable @SerialName("deleted") data class Deleted(val id: String): Event

Полиморфная сериализация требует discriminator и регистрации/известной иерархии; внешний тег является частью долговременного контракта. Наблюдаемое поведение выводят из того, что serialName выбирает поток, в котором декодируется подтип. Здесь действует следующее правило: Аннотация автоматически мигрирует старые поля подтипа. Причину поведения формулируют так: Они заставляют сериализатор хранить оба имени одновременно. Объяснение опирается на утверждение: Без них sealed-полиморфизм невозможен даже внутри одной версии процесса.

Вопрос 8 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
val json = Json { ignoreUnknownKeys = true }
@Serializable data class User(val id: Int)
val user = json.decodeFromString<User>("""{"id":1,"name":"Ada"}""")

Добавить защитную проверку перед фрагментом, поскольку поле name автоматически добавится в объект через reflection. Включать толерантность осознанно, вести наблюдение за новыми полями и отдельно валидировать данные, которые влияют на безопасность. Спрятать участок за вспомогательной функцией, сохранив предположение: Декодирование в показанном сценарии падает, потому что data class не содержит name. Оставить реализацию без изменений и закрепить тестом предположение: IgnoreUnknownKeys игнорирует также отсутствие обязательного id. Перенести проверку в вызывающий код, исходя из того, что user.id станет null из-за присутствия лишнего ключа.

Вопрос 9 из 30

Где поведение «Новое поле с default» требует отдельной проверки?

Проверить соседний случай: Он позволяет изменить тип id без миграции. Отдельно проверить предположение, что он заставляет старые приложения понимать nickname. Добавить регрессию на гипотезу: Default применяется также к полю с неверным типом вместо ошибки. Default может скрыть потерю данных, если поле исчезло из-за ошибки producer, а не из-за старой версии. Проверить границу полезности утверждения: Default добавляет поле в уже сохранённые файлы без их чтения.

Вопрос 10 из 30

Какую обратную сторону имеет решение для «Исторические JSON fixtures»: Хранить fixtures рядом с номером схемы и запускать их в CI при обновлении Kotlin, plugin и настроек Json?

Обратная сторона изменения состоит в том, что мок serializer, который в показанном сценарии возвращает Profile по умолчанию. Практическое ограничение подхода: Один JSON, заново сгенерированный текущей версией serializer. Компромисс состоит в утверждении: Только snapshot отформатированной строки с фиксированным порядком полей. Набор исторических fixtures растёт, но позволяет безопасно рефакторить внутреннюю модель без гадания о старых данных. Решение оправдано лишь при условии: Случайный текст, для которого проверяется лишь факт любого исключения.

Вопрос 11 из 30

Почему DTO отделён от доменной модели?

// Проследите фактическое выполнение без изменения кода.
class UserGateway(private val json: Json, private val transport: Transport) {
    suspend fun load(): User = transport.get()
        .let { json.decodeFromString<UserDto>(it) }
        .validate()
        .toDomain()
}

После toDomain сериализатор автоматически кэширует пользователя. DTO нужен, чтобы каждый decode запускался на отдельном потоке. Разделение устраняет необходимость версионировать внешний JSON. DTO удерживает внешнюю схему и валидацию на границе до создания доменного `User`. UserDto гарантированно immutable независимо от типов его свойств.

Вопрос 12 из 30

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

// Проследите фактическое выполнение без изменения кода.
@Serializable
data class User(val id: Long, val name: String)

val json = Json.encodeToString(User(1, "Ada"))

Декодер обязан отвергать любое изменение пробелов. Порядок свойств data class гарантирует байтово одинаковый JSON во всех версиях и настройках. Аннотация автоматически шифрует поля перед выводом. @Serializable применяет Java Serializable и пишет бинарный ObjectStream. Схема значений и имён должна декодироваться обратно; порядок JSON-полей не следует считать частью контракта.

Вопрос 13 из 30

Какой тест лучше всего защищает край контракта «Лишнее поле во входном JSON»?

Опечатка в ожидаемом поле тоже может стать «неизвестным» и тихо скрыться, если у целевого свойства есть default. Зафиксировать сценарий, где ожидается: IgnoreUnknownKeys игнорирует также отсутствие обязательного id. Считать опасной границей ситуацию, где поле name автоматически добавится в объект через reflection. Проверить крайний ввод, при котором user.id станет null из-за присутствия лишнего ключа. Добавить регрессию на гипотезу: Декодирование в показанном сценарии падает, потому что data class не содержит name.

Вопрос 14 из 30

Команда собирается хранить версию или явный мигратор для долговременных данных и тестировать чтение fixtures всех поддерживаемых версий. Что придётся учитывать после внедрения в «Новое поле с default»?

Главный риск формулируют так: Он заставляет старые приложения понимать nickname. После внедрения придётся исходить из того, что default применяется также к полю с неверным типом вместо ошибки. Толерантная схема снижает цену развёртывания, но увеличивает период поддержки старых смыслов и тестовую матрицу. Граница полезности решения описывается условием: Он позволяет изменить тип id без миграции. После правки останется ограничение: Default добавляет поле в уже сохранённые файлы без их чтения.

Вопрос 15 из 30

Какой набор regression fixtures полезнее всего?

// Проследите фактическое выполнение без изменения кода.
val old = """{"id":"u1"}"""
val current = Json.decodeFromString<Profile>(old)

Один JSON, заново сгенерированный текущей версией serializer. Старый минимальный, текущий полный, неизвестное поле и повреждённые типы. Мок serializer, который в показанном сценарии возвращает Profile по умолчанию. Только snapshot отформатированной строки с фиксированным порядком полей. Случайный текст, для которого проверяется лишь факт любого исключения.

Вопрос 16 из 30

Какое утверждение точнее всего объясняет поведение фрагмента «DTO на внешней границе»?

// На ревью требуется объяснить причину поведения.
class UserGateway(private val json: Json, private val transport: Transport) {
    suspend fun load(): User = transport.get()
        .let { json.decodeFromString<UserDto>(it) }
        .validate()
        .toDomain()
}

Объяснение опирается на утверждение: Разделение устраняет необходимость версионировать внешний JSON. Причину поведения формулируют так: После toDomain сериализатор автоматически кэширует пользователя. Сериализация — инфраструктурная граница: внешние данные сначала декодируют, затем валидируют и только потом допускают в домен. Контракт здесь понимают так: DTO нужен, чтобы каждый decode запускался на отдельном потоке. Здесь действует следующее правило: UserDto гарантированно immutable независимо от типов его свойств.

Вопрос 17 из 30

Какой контракт определяет наблюдаемый результат «Generated serializer модели»?

// На ревью требуется объяснить причину поведения.
@Serializable
data class User(val id: Long, val name: String)

val json = Json.encodeToString(User(1, "Ada"))

Причину поведения формулируют так: Порядок свойств data class гарантирует байтово одинаковый JSON во всех версиях и настройках. Здесь действует следующее правило: Аннотация автоматически шифрует поля перед выводом. Объяснение опирается на утверждение: @Serializable применяет Java Serializable и пишет бинарный ObjectStream. Kotlinx.serialization генерирует serializer на этапе компиляции; формат и настройки определяют представление и строгость. Наблюдаемое поведение выводят из того, что декодер обязан отвергать любое изменение пробелов.

Вопрос 18 из 30

Какое изменение лучше всего защищает границу «Стабильные теги подтипов»?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Serializable sealed interface Event
@Serializable @SerialName("created") data class Created(val id: String): Event
@Serializable @SerialName("deleted") data class Deleted(val id: String): Event

Ограничиться поясняющим комментарием о том, что аннотация автоматически мигрирует старые поля подтипа. Сохранить API и считать достаточным условие: SerialName выбирает поток, в котором декодируется подтип. Назначить короткие стабильные теги, протестировать неизвестный подтип и не использовать обфусцируемое имя класса как протокол. Добавить локальную обработку результата, потому что без них sealed-полиморфизм невозможен даже внутри одной версии процесса. Зафиксировать текущее поведение регрессионным тестом: Они заставляют сериализатор хранить оба имени одновременно.

Вопрос 19 из 30

Почему default у нового поля помогает читать старые документы?

// Проследите фактическое выполнение без изменения кода.
@Serializable
data class Profile(
    val id: String,
    val nickname: String = ""
)

Default добавляет поле в уже сохранённые файлы без их чтения. Default применяется также к полю с неверным типом вместо ошибки. При отсутствии `nickname` декодер возьмёт default, поэтому старый JSON останется допустимым. Он заставляет старые приложения понимать nickname. Он позволяет изменить тип id без миграции.

Вопрос 20 из 30

Почему поведение «Исторические JSON fixtures» не является случайностью?

// На ревью требуется объяснить причину поведения.
val old = """{"id":"u1"}"""
val current = Json.decodeFromString<Profile>(old)

Ключевым считают контракт: Случайный текст, для которого проверяется лишь факт любого исключения. Такой результат объясняют тем, что мок serializer, который в показанном сценарии возвращает Profile по умолчанию. Наблюдаемое поведение выводят из того, что только snapshot отформатированной строки с фиксированным порядком полей. Объяснение опирается на утверждение: Один JSON, заново сгенерированный текущей версией serializer. Golden/fixture-тесты нужны именно на границах версий; round-trip текущей модели не доказывает чтение исторических данных.

Вопрос 21 из 30

Какая правка устраняет причину риска в «DTO на внешней границе», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
class UserGateway(private val json: Json, private val transport: Transport) {
    suspend fun load(): User = transport.get()
        .let { json.decodeFromString<UserDto>(it) }
        .validate()
        .toDomain()
}

Не разделять один stateful Json-конфиг между недоверенными протоколами с разными модулями типов без явной политики. Перенести проверку в вызывающий код, исходя из того, что разделение устраняет необходимость версионировать внешний JSON. Вынести участок в отдельный метод, считая верным следующее: UserDto гарантированно immutable независимо от типов его свойств. Спрятать участок за вспомогательной функцией, сохранив предположение: DTO нужен, чтобы каждый decode запускался на отдельном потоке. Добавить защитную проверку перед фрагментом, поскольку после toDomain сериализатор автоматически кэширует пользователя.

Вопрос 22 из 30

Как укрепить «Generated serializer модели», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Serializable
data class User(val id: Long, val name: String)

val json = Json.encodeToString(User(1, "Ada"))

Перенести проверку в вызывающий код, исходя из того, что @Serializable применяет Java Serializable и пишет бинарный ObjectStream. Добавить защитную проверку перед фрагментом, поскольку порядок свойств data class гарантирует байтово одинаковый JSON во всех версиях и настройках. Вынести участок в отдельный метод, считая верным следующее: Аннотация автоматически шифрует поля перед выводом. Оставить реализацию без изменений и закрепить тестом предположение: Декодер обязан отвергать любое изменение пробелов. Проверять round-trip и конкретные договорённые имена, а не хрупкое полное сравнение строки без необходимости.

Вопрос 23 из 30

Какой сценарий выявит скрытое ограничение «Стабильные теги подтипов»?

Добавить тест на состояние, при котором без них sealed-полиморфизм невозможен даже внутри одной версии процесса. Открытый полиморфизм нуждается в SerializersModule; незарегистрированный подтип завершит декодирование ошибкой. Проверить соседний случай: SerialName выбирает поток, в котором декодируется подтип. Проверить границу полезности утверждения: Они заставляют сериализатор хранить оба имени одновременно. Отдельно проверить предположение, что аннотация автоматически мигрирует старые поля подтипа.

Вопрос 24 из 30

Решение для «Лишнее поле во входном JSON»: Включать толерантность осознанно, вести наблюдение за новыми полями и отдельно валидировать данные, которые влияют на безопасность. Что в нём остаётся не бесплатным?

Сопровождение усложнится, если окажется, что поле name автоматически добавится в объект через reflection. Решение оправдано лишь при условии: Декодирование в показанном сценарии падает, потому что data class не содержит name. Главная цена решения — необходимость учитывать, что ignoreUnknownKeys игнорирует также отсутствие обязательного id. После правки останется ограничение: User.id станет null из-за присутствия лишнего ключа. Мягкий reader переживает расширение producer, но способен незаметно терять данные и замедлять обнаружение рассинхронизации схем.

Вопрос 25 из 30

Что следует изменить прежде всего во фрагменте «Исторические JSON fixtures»?

// Сохраните назначение фрагмента, но укрепите его контракт.
val old = """{"id":"u1"}"""
val current = Json.decodeFromString<Profile>(old)

Зафиксировать текущее поведение регрессионным тестом: Случайный текст, для которого проверяется лишь факт любого исключения. Добавить локальную обработку результата, потому что мок serializer, который в показанном сценарии возвращает Profile по умолчанию. Оставить структуру прежней, документировав утверждение: Один JSON, заново сгенерированный текущей версией serializer. Обернуть операцию проверкой и не менять основной контракт: Только snapshot отформатированной строки с фиксированным порядком полей. Хранить fixtures рядом с номером схемы и запускать их в CI при обновлении Kotlin, plugin и настроек Json.

Вопрос 26 из 30

Какой редкий случай способен сломать наивную трактовку «DTO на внешней границе»?

Добавить граничный тест на утверждение: Разделение устраняет необходимость версионировать внешний JSON. Полиморфный module, допускающий лишние классы, может расширить поверхность входа; whitelist должен быть минимальным. Воспроизвести редкий сценарий, где userDto гарантированно immutable независимо от типов его свойств. Проверить, сохраняется ли контракт, когда после toDomain сериализатор автоматически кэширует пользователя. Зафиксировать сценарий, где ожидается: DTO нужен, чтобы каждый decode запускался на отдельном потоке.

Вопрос 27 из 30

Какой контрпример точнее всего показывает границу «Generated serializer модели»?

Отдельно воспроизвести случай, в котором декодер обязан отвергать любое изменение пробелов. Добавить граничный тест на утверждение: @Serializable применяет Java Serializable и пишет бинарный ObjectStream. Проверить, сохраняется ли контракт, когда порядок свойств data class гарантирует байтово одинаковый JSON во всех версиях и настройках. Воспроизвести редкий сценарий, где аннотация автоматически шифрует поля перед выводом. Пользовательский serializer обязан сохранять симметрию encode/decode и корректно описывать descriptor для инструментов.

Вопрос 28 из 30

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

Главный риск формулируют так: Они заставляют сериализатор хранить оба имени одновременно. Полиморфный формат естественно отражает варианты, но усложняет совместимость и контроль допустимых типов. После внедрения придётся исходить из того, что без них sealed-полиморфизм невозможен даже внутри одной версии процесса. Цена упрощения проявится, если serialName выбирает поток, в котором декодируется подтип. Практическое ограничение подхода: Аннотация автоматически мигрирует старые поля подтипа.

Вопрос 29 из 30

Что произойдёт?

// Проследите фактическое выполнение без изменения кода.
val json = Json { ignoreUnknownKeys = true }
@Serializable data class User(val id: Int)
val user = json.decodeFromString<User>("""{"id":1,"name":"Ada"}""")

Декодирование в показанном сценарии падает, потому что data class не содержит name. Поле name автоматически добавится в объект через reflection. Декодирование успешно даст `User(1)`: неизвестное поле name будет проигнорировано настройкой. User.id станет null из-за присутствия лишнего ключа. IgnoreUnknownKeys игнорирует также отсутствие обязательного id.

Вопрос 30 из 30

На какой контракт языка или библиотеки опирается «Новое поле с default»?

// На ревью требуется объяснить причину поведения.
@Serializable
data class Profile(
    val id: String,
    val nickname: String = ""
)

Наблюдаемое поведение выводят из того, что default применяется также к полю с неверным типом вместо ошибки. Совместимое развитие обычно добавляет необязательное/default-поле и сохраняет имена/смысл существующих; удаление и смена типа требуют миграции. Поведение связывают с правилом: Default добавляет поле в уже сохранённые файлы без их чтения. Объяснение опирается на утверждение: Он заставляет старые приложения понимать nickname. Контракт здесь понимают так: Он позволяет изменить тип id без миграции.