Серверный Kotlin — бесплатный тест онлайн

Вопрос 1 из 30

Какое свойство нельзя вывести только из слова `suspend`?

// Проследите фактическое выполнение без изменения кода.
suspend fun transfer(from: Id, to: Id, amount: Money) = database.transaction {
    debit(from, amount)
    credit(to, amount)
}

Suspend автоматически делает обе записи атомарными. Credit может выполниться раньше debit из-за компилятора. Транзакционность и неблокирующий характер задают API базы и драйвер, а не `suspend`. Ошибки debit преобразуются в успешный rollback-результат. Любая coroutine сохраняет одно JDBC-соединение при смене потока без поддержки библиотеки.

Вопрос 2 из 30

Что точнее описывает механику фрагмента «In-process HTTP-тест»?

// На ревью требуется объяснить причину поведения.
testApplication {
    application { module(fakeRepo) }
    client.get("/users/42").apply {
        assertEquals(HttpStatusCode.OK, status)
    }
}

Механика примера описывается утверждением: FakeRepo автоматически проверяет SQL-миграции. Серверная тестовая пирамида сочетает unit домена, in-process HTTP и ограниченные интеграционные тесты реальной базы/очереди. Ключевым считают контракт: Он доказывает производительность под боевой нагрузкой. Здесь действует следующее правило: Он полностью заменяет тест с реальной базой и обратный прокси. Из правил языка или API следует, что он не запускает application module и проверяет только клиентский URL builder.

Вопрос 3 из 30

Что изменить в «Транзакционный outbox», чтобы скрытое допущение стало явным контрактом?

// Сохраните назначение фрагмента, но укрепите его контракт.
class OrderService(
    private val repo: OrderRepository,
    private val outbox: Outbox
) {
    suspend fun place(cmd: PlaceOrder) = repo.transaction {
        val order = Order.create(cmd)
        save(order)
        outbox.add(OrderPlaced(order.id))
        order.id
    }
}

Перенести проверку в вызывающий код, исходя из того, что outbox делает обработчик события exactly-once без idempotency потребителя. Обернуть операцию проверкой и не менять основной контракт: После записи outbox повторная доставка невозможна. Добавить ключ идемпотентности, статус/lease публикации, метрики отставания и безопасную повторную обработку. Вынести участок в отдельный метод, считая верным следующее: Он заменяет транзакцию базы распределённой блокировкой. Оставить реализацию без изменений и закрепить тестом предположение: Он автоматически публикует событие до commit и откатывает внешний брокер.

Вопрос 4 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
// Ktor
fun Application.healthModule() {
    routing {
        get("/health") { call.respondText("ok") }
    }
}

Собрать тонкий вертикальный прототип с реальной авторизацией, базой, метриками и deployment, а не сравнивать учебные маршруты. Вынести участок в отдельный метод, считая верным следующее: Ktor автоматически делает любой обработчик неблокирующим, даже при JDBC-вызове. Перенести проверку в вызывающий код, исходя из того, что ktor подходит только для Android, а Spring — только для Java-кода. Оставить структуру прежней, документировав утверждение: Выбор можно однозначно сделать по числу строк hello-world. Оставить реализацию без изменений и закрепить тестом предположение: Spring не поддерживает suspend endpoints ни в каком виде.

Вопрос 5 из 30

Какой редкий случай способен сломать наивную трактовку «Три HTTP-исхода»?

Добавить граничный тест на утверждение: Отсутствующий user сериализуется как 200 null. Повторная попытка `respond` после уже отправленного тела приводит к ошибке; контроль потока должен гарантировать один ответ. Отдельно воспроизвести случай, в котором badRequest и NotFound выбираются по исключению компилятора. Воспроизвести редкий сценарий, где после первого respond выполнение обязательно продолжается до последнего respond. Проверить, сохраняется ли контракт, когда любая ошибка превращается в 500, потому что return@get запрещён.

Вопрос 6 из 30

В «Параллельная агрегация запросов» выбрали решение: Ограничить параллелизм, задать timeout и выбрать fail-fast либо частичный результат как явный доменный контракт. Какова его реальная цена?

Параллельный fan-out снижает latency, но увеличивает нагрузку, вероятность частичного сбоя и сложность трассировки. Граница полезности решения описывается условием: AwaitAll сортирует результаты по времени завершения. Главный риск формулируют так: Каждый async создаёт выделенный поток и не связан с отменой HTTP-запроса. Главная цена решения — необходимость учитывать, что остальные запросы продолжатся независимо после возврата функции. Сопровождение усложнится, если окажется, что она вернёт список с null на месте ошибки автоматически.

Вопрос 7 из 30

Какое изменение лучше всего защищает границу «In-process HTTP-тест»?

// Сохраните назначение фрагмента, но укрепите его контракт.
testApplication {
    application { module(fakeRepo) }
    client.get("/users/42").apply {
        assertEquals(HttpStatusCode.OK, status)
    }
}

Проверить успешный, validation, auth и сценарии отказа; для базы поднимать совместимый контейнер и накатывать реальные migrations. Зафиксировать текущее поведение регрессионным тестом: Он доказывает производительность под боевой нагрузкой. Сохранить API и считать достаточным условие: Он не запускает application module и проверяет только клиентский URL builder. Передать ответственность владельцу вызова, предполагая, что он полностью заменяет тест с реальной базой и обратный прокси. Ограничиться поясняющим комментарием о том, что fakeRepo автоматически проверяет SQL-миграции.

Вопрос 8 из 30

Где упрощённое объяснение «Транзакционный outbox» перестаёт работать?

Добавить тест на состояние, при котором после записи outbox повторная доставка невозможна. Добавить граничный тест на утверждение: Outbox делает обработчик события exactly-once без idempotency потребителя. Отдельно воспроизвести случай, в котором он автоматически публикует событие до commit и откатывает внешний брокер. Воспроизвести редкий сценарий, где он заменяет транзакцию базы распределённой блокировкой. Долгая обработка события в той же транзакции увеличивает блокировки; outbox должен хранить намерение, а не выполнять интеграцию.

Вопрос 9 из 30

Где упрощённое объяснение «Маршрут как малая часть выбора» перестаёт работать?

Добавить граничный тест на утверждение: Ktor подходит только для Android, а Spring — только для Java-кода. Проверить границу полезности утверждения: Выбор можно однозначно сделать по числу строк hello-world. Воспроизвести редкий сценарий, где ktor автоматически делает любой обработчик неблокирующим, даже при JDBC-вызове. Отдельно воспроизвести случай, в котором spring не поддерживает suspend endpoints ни в каком виде. Фреймворк с coroutine API не исправляет блокирующий драйвер или библиотеку; thread model нужно проверять на каждом адаптере.

Вопрос 10 из 30

Что может усложниться в сопровождении после изменения «Три HTTP-исхода»: Вынести проверку параметров в typed request/validation и централизовать единый формат ошибок?

Решение оправдано лишь при условии: Отсутствующий user сериализуется как 200 null. Сопровождение усложнится, если окажется, что после первого respond выполнение обязательно продолжается до последнего respond. Ранние ответы делают успешный сценарий коротким, но повторяющиеся проверки по маршрутам лучше оформить плагином или middleware. Новый риск связан с тем, что любая ошибка превращается в 500, потому что return@get запрещён. Обратная сторона изменения состоит в том, что badRequest и NotFound выбираются по исключению компилятора.

Вопрос 11 из 30

Как поведёт себя функция при ошибке одного `load`?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
suspend fun aggregate(ids: List<String>): List<Item> = coroutineScope {
    ids.map { id -> async { client.load(id) } }.awaitAll()
}

`coroutineScope` завершится ошибкой и отменит остальные дочерние запросы. Каждый async создаёт выделенный поток и не связан с отменой HTTP-запроса. AwaitAll сортирует результаты по времени завершения. Остальные запросы продолжатся независимо после возврата функции. Она вернёт список с null на месте ошибки автоматически.

Вопрос 12 из 30

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

// На ревью требуется объяснить причину поведения.
suspend fun transfer(from: Id, to: Id, amount: Money) = database.transaction {
    debit(from, amount)
    credit(to, amount)
}

Здесь действует следующее правило: Ошибки debit преобразуются в успешный rollback-результат. Транзакция должна удерживать правильный connection/context и явно задавать rollback; coroutine-friendly API не равно реактивному драйверу. Причину поведения формулируют так: Suspend автоматически делает обе записи атомарными. Ключевым считают контракт: Credit может выполниться раньше debit из-за компилятора. Объяснение опирается на утверждение: Любая coroutine сохраняет одно JDBC-соединение при смене потока без поддержки библиотеки.

Вопрос 13 из 30

Решение для «Транзакционный outbox»: Добавить ключ идемпотентности, статус/lease публикации, метрики отставания и безопасную повторную обработку. Что в нём остаётся не бесплатным?

Главная цена решения — необходимость учитывать, что после записи outbox повторная доставка невозможна. Решение оправдано лишь при условии: Outbox делает обработчик события exactly-once без idempotency потребителя. Появляется дополнительная таблица и worker, но исчезает опасное окно между записью домена и сообщением. Сопровождение усложнится, если окажется, что он заменяет транзакцию базы распределённой блокировкой. Обратная сторона изменения состоит в том, что он автоматически публикует событие до commit и откатывает внешний брокер.

Вопрос 14 из 30

Решение для «Маршрут как малая часть выбора»: Собрать тонкий вертикальный прототип с реальной авторизацией, базой, метриками и deployment, а не сравнивать учебные маршруты. Что в нём остаётся не бесплатным?

Обратная сторона изменения состоит в том, что spring не поддерживает suspend endpoints ни в каком виде. После правки останется ограничение: Выбор можно однозначно сделать по числу строк hello-world. Решение оправдано лишь при условии: Ktor подходит только для Android, а Spring — только для Java-кода. Лёгкий стек даёт контроль и быстрый старт, развитая платформа сокращает интеграционный код ценой большей сложности и ресурсов. Сопровождение усложнится, если окажется, что ktor автоматически делает любой обработчик неблокирующим, даже при JDBC-вызове.

Вопрос 15 из 30

Какие три исхода явно разделены?

// Проследите фактическое выполнение без изменения кода.
get("/users/{id}") {
    val id = call.parameters["id"] ?: return@get call.respond(HttpStatusCode.BadRequest)
    val user = service.find(id) ?: return@get call.respond(HttpStatusCode.NotFound)
    call.respond(user)
}

Любая ошибка превращается в 500, потому что return@get запрещён. Отсутствующий user сериализуется как 200 null. Некорректный запрос, отсутствующий пользователь и успешный ответ. После первого respond выполнение обязательно продолжается до последнего respond. BadRequest и NotFound выбираются по исключению компилятора.

Вопрос 16 из 30

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
suspend fun aggregate(ids: List<String>): List<Item> = coroutineScope {
    ids.map { id -> async { client.load(id) } }.awaitAll()
}

Причина результата в том, что остальные запросы продолжатся независимо после возврата функции. Поведение связывают с правилом: Каждый async создаёт выделенный поток и не связан с отменой HTTP-запроса. Из правил языка или API следует, что она вернёт список с null на месте ошибки автоматически. Семантика фрагмента приводит к тому, что awaitAll сортирует результаты по времени завершения. Structured concurrency связывает fan-out запросы с жизненным циклом входящего запроса; отмена клиента должна доходить до детей.

Вопрос 17 из 30

Какую правку выбрать, чтобы сохранить назначение «Suspend-функция внутри транзакции» и убрать хрупкость?

// Сохраните назначение фрагмента, но укрепите его контракт.
suspend fun transfer(from: Id, to: Id, amount: Money) = database.transaction {
    debit(from, amount)
    credit(to, amount)
}

Зафиксировать текущее поведение регрессионным тестом: Credit может выполниться раньше debit из-за компилятора. Использовать поддерживаемый транзакционный оператор, не запускать параллельные запросы внутри одной connection-транзакции без гарантии драйвера. Передать ответственность владельцу вызова, предполагая, что ошибки debit преобразуются в успешный rollback-результат. Оставить структуру прежней, документировав утверждение: Любая coroutine сохраняет одно JDBC-соединение при смене потока без поддержки библиотеки. Вынести участок в отдельный метод, считая верным следующее: Suspend автоматически делает обе записи атомарными.

Вопрос 18 из 30

Какой дополнительный сценарий нужен для «In-process HTTP-тест»?

Зафиксировать сценарий, где ожидается: Он не запускает application module и проверяет только клиентский URL builder. Считать опасной границей ситуацию, где он полностью заменяет тест с реальной базой и обратный прокси. In-memory база может отличаться транзакциями и SQL-диалектом от рабочей среды, создавая ложную уверенность. Добавить граничный тест на утверждение: FakeRepo автоматически проверяет SQL-миграции. Проверить крайний ввод, при котором он доказывает производительность под боевой нагрузкой.

Вопрос 19 из 30

Что определяет выбор Ktor или Spring сильнее синтаксиса маршрута?

// Проследите фактическое выполнение без изменения кода.
// Ktor
fun Application.healthModule() {
    routing {
        get("/health") { call.respondText("ok") }
    }
}

Экосистема, модель конфигурации, требования команды, наблюдаемость, интеграции и цена запуска/сопровождения. Выбор можно однозначно сделать по числу строк hello-world. Ktor подходит только для Android, а Spring — только для Java-кода. Ktor автоматически делает любой обработчик неблокирующим, даже при JDBC-вызове. Spring не поддерживает suspend endpoints ни в каком виде.

Вопрос 20 из 30

Какое правило нужно применить, чтобы объяснить «Три HTTP-исхода»?

// На ревью требуется объяснить причину поведения.
get("/users/{id}") {
    val id = call.parameters["id"] ?: return@get call.respond(HttpStatusCode.BadRequest)
    val user = service.find(id) ?: return@get call.respond(HttpStatusCode.NotFound)
    call.respond(user)
}

Ключевым считают контракт: Отсутствующий user сериализуется как 200 null. Из правил языка или API следует, что после первого respond выполнение обязательно продолжается до последнего respond. Такой результат объясняют тем, что badRequest и NotFound выбираются по исключению компилятора. Здесь действует следующее правило: Любая ошибка превращается в 500, потому что return@get запрещён. HTTP-маршрут обязан явно преобразовать вход, доменный результат и ошибку в статус/тело, не смешивая их с исключениями инфраструктуры.

Вопрос 21 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
suspend fun aggregate(ids: List<String>): List<Item> = coroutineScope {
    ids.map { id -> async { client.load(id) } }.awaitAll()
}

Передать ответственность владельцу вызова, предполагая, что она вернёт список с null на месте ошибки автоматически. Добавить локальную обработку результата, потому что остальные запросы продолжатся независимо после возврата функции. Ограничить параллелизм, задать timeout и выбрать fail-fast либо частичный результат как явный доменный контракт. Сохранить API и считать достаточным условие: AwaitAll сортирует результаты по времени завершения. Ограничиться поясняющим комментарием о том, что каждый async создаёт выделенный поток и не связан с отменой HTTP-запроса.

Вопрос 22 из 30

Какой контрпример точнее всего показывает границу «Suspend-функция внутри транзакции»?

Проверить, сохраняется ли контракт, когда suspend автоматически делает обе записи атомарными. Воспроизвести редкий сценарий, где ошибки debit преобразуются в успешный rollback-результат. Добавить граничный тест на утверждение: Любая coroutine сохраняет одно JDBC-соединение при смене потока без поддержки библиотеки. Проверить границу полезности утверждения: Credit может выполниться раньше debit из-за компилятора. Отмена корутины во время блокирующего JDBC может не остановить запрос немедленно, а соединение требует корректного возврата в pool.

Вопрос 23 из 30

Какое ограничение сохранится после правки «In-process HTTP-тест»: Проверить успешный, validation, auth и сценарии отказа; для базы поднимать совместимый контейнер и накатывать реальные migrations?

Решение оправдано лишь при условии: FakeRepo автоматически проверяет SQL-миграции. Компромисс состоит в утверждении: Он не запускает application module и проверяет только клиентский URL builder. Цена упрощения проявится, если он полностью заменяет тест с реальной базой и обратный прокси. In-process тесты быстры и широки по HTTP-слою, но не видят сеть, TLS, прокси и настройки deployment. Практическое ограничение подхода: Он доказывает производительность под боевой нагрузкой.

Вопрос 24 из 30

Какой сбой предотвращает outbox в той же транзакции?

// Проследите фактическое выполнение без изменения кода.
class OrderService(
    private val repo: OrderRepository,
    private val outbox: Outbox
) {
    suspend fun place(cmd: PlaceOrder) = repo.transaction {
        val order = Order.create(cmd)
        save(order)
        outbox.add(OrderPlaced(order.id))
        order.id
    }
}

Outbox делает обработчик события exactly-once без idempotency потребителя. После записи outbox повторная доставка невозможна. Заказ и намерение отправить событие фиксируются одной транзакцией. Он заменяет транзакцию базы распределённой блокировкой. Он автоматически публикует событие до commit и откатывает внешний брокер.

Вопрос 25 из 30

Какая небольшая правка заметно повышает надёжность «Три HTTP-исхода»?

// Сохраните назначение фрагмента, но укрепите его контракт.
get("/users/{id}") {
    val id = call.parameters["id"] ?: return@get call.respond(HttpStatusCode.BadRequest)
    val user = service.find(id) ?: return@get call.respond(HttpStatusCode.NotFound)
    call.respond(user)
}

Вынести проверку параметров в typed request/validation и централизовать единый формат ошибок. Зафиксировать текущее поведение регрессионным тестом: Отсутствующий user сериализуется как 200 null. Добавить локальную обработку результата, потому что badRequest и NotFound выбираются по исключению компилятора. Сохранить API и считать достаточным условие: После первого respond выполнение обязательно продолжается до последнего respond. Передать ответственность владельцу вызова, предполагая, что любая ошибка превращается в 500, потому что return@get запрещён.

Вопрос 26 из 30

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

Считать опасной границей ситуацию, где awaitAll сортирует результаты по времени завершения. Проверить соседний случай: Она вернёт список с null на месте ошибки автоматически. Добавить регрессию на гипотезу: Остальные запросы продолжатся независимо после возврата функции. Проверить крайний ввод, при котором каждый async создаёт выделенный поток и не связан с отменой HTTP-запроса. Мгновенный запуск тысяч async способен перегрузить downstream раньше, чем timeout начнёт помогать.

Вопрос 27 из 30

В «Suspend-функция внутри транзакции» выбрали решение: Использовать поддерживаемый транзакционный оператор, не запускать параллельные запросы внутри одной connection-транзакции без гарантии драйвера. Какова его реальная цена?

Сопровождение усложнится, если окажется, что suspend автоматически делает обе записи атомарными. Граница полезности решения описывается условием: Ошибки debit преобразуются в успешный rollback-результат. Главный риск формулируют так: Credit может выполниться раньше debit из-за компилятора. После правки останется ограничение: Любая coroutine сохраняет одно JDBC-соединение при смене потока без поддержки библиотеки. Транзакция защищает инвариант, но держит ресурсы и блокировки; внешние сетевые вызовы внутри неё резко увеличивают риск.

Вопрос 28 из 30

Что даёт такой тест по сравнению с прямым вызовом service?

// Проследите фактическое выполнение без изменения кода.
testApplication {
    application { module(fakeRepo) }
    client.get("/users/42").apply {
        assertEquals(HttpStatusCode.OK, status)
    }
}

Он проверяет routing, плагины, HTTP-кодирование и сериализацию in-process. Он доказывает производительность под боевой нагрузкой. Он не запускает application module и проверяет только клиентский URL builder. FakeRepo автоматически проверяет SQL-миграции. Он полностью заменяет тест с реальной базой и обратный прокси.

Вопрос 29 из 30

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

// На ревью требуется объяснить причину поведения.
class OrderService(
    private val repo: OrderRepository,
    private val outbox: Outbox
) {
    suspend fun place(cmd: PlaceOrder) = repo.transaction {
        val order = Order.create(cmd)
        save(order)
        outbox.add(OrderPlaced(order.id))
        order.id
    }
}

Поведение связывают с правилом: Outbox делает обработчик события exactly-once без idempotency потребителя. Контракт здесь понимают так: Он автоматически публикует событие до commit и откатывает внешний брокер. Причину поведения формулируют так: Он заменяет транзакцию базы распределённой блокировкой. Объяснение опирается на утверждение: После записи outbox повторная доставка невозможна. Transactional outbox решает атомарность локальной БД и будущей публикации; доставщик и потребители всё равно должны переносить повторы.

Вопрос 30 из 30

Что в семантике Kotlin или используемого API объясняет «Маршрут как малая часть выбора»?

// На ревью требуется объяснить причину поведения.
// Ktor
fun Application.healthModule() {
    routing {
        get("/health") { call.respondText("ok") }
    }
}

Поведение связывают с правилом: Ktor автоматически делает любой обработчик неблокирующим, даже при JDBC-вызове. Причина результата в том, что ktor подходит только для Android, а Spring — только для Java-кода. Контракт здесь понимают так: Выбор можно однозначно сделать по числу строк hello-world. Семантика фрагмента приводит к тому, что spring не поддерживает suspend endpoints ни в каком виде. Оба стека поддерживают серверный Kotlin, но различаются уровнем opinionated-инфраструктуры, интеграциями и операционной моделью.