Тестирование Kotlin-кода — бесплатный тест онлайн

Вопрос 1 из 30

Решение для «Управляемый lifecycle worker»: Добавить идемпотентный start или запрет повторного запуска, обработку ошибки process и deterministic shutdown. Что в нём остаётся не бесплатным?

Обратная сторона изменения состоит в том, что возвращать Job не нужно: garbage collector остановит collector. Решение оправдано лишь при условии: Worker должен создавать GlobalScope внутри, чтобы тест не мог случайно отменить работу. Сопровождение усложнится, если окажется, что тестовая очередь должна использовать Thread.sleep для каждого элемента. Явный lifecycle добавляет API, зато позволяет безопасный shutdown, тесты и наблюдение аварий фоновой работы. Главная цена решения — необходимость учитывать, что collect автоматически завершается после первого элемента.

Вопрос 2 из 30

Что станет новой точкой внимания после изменения «Внедрённые часы в unit-тесте»: Составить таблицу границ периода и оставить системный Clock только в рабочей среде adapter?

Цена упрощения проявится, если добавить retry теста при несовпадении даты. Fake делает тест быстрым и ясным, но интеграционный тест должен проверить реальный адаптер времени и конфигурацию зоны. После внедрения придётся исходить из того, что использовать LocalDate.now() и запускать тест только в нужный день. Практическое ограничение подхода: Мокировать Money multiplication, не проверяя условие скидки. Компромисс состоит в утверждении: Сравнивать только, что результат положительный.

Вопрос 3 из 30

Что проверяется без реальной секунды ожидания?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
@Test fun emits_after_delay() = runTest {
    val flow = flow { delay(1_000); emit(1) }
    val deferred = async { flow.first() }
    advanceTimeBy(999)
    assertFalse(deferred.isCompleted)
    advanceTimeBy(1)
    assertEquals(1, deferred.await())
}

Скорость реального Dispatchers.IO под нагрузкой. До 1000 мс результата нет, после границы `first` возвращает 1. Точное соответствие виртуальной миллисекунды системному wall clock. Отсутствие любых утечек jobs после теста без завершения async. Что delay блокирует тестовый поток на 1000 мс.

Вопрос 4 из 30

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

// На ревью требуется объяснить причину поведения.
class ReversePropertyTest : StringSpec({
    property("reverse twice") {
        checkAll<String> { s -> s.reversed().reversed() shouldBe s }
    }
})

Наблюдаемое поведение выводят из того, что он гарантирует отсутствие дефектов в реализации reversed. Property-based testing проверяет общий закон на многих данных; качество зависит от генераторов, shrinking и выбранного инварианта. Здесь действует следующее правило: Он проверяет только одну случайную строку без воспроизводимого seed. Контракт здесь понимают так: Он математически доказывает свойство для всех возможных строк. Объяснение опирается на утверждение: Он заменяет тесты Unicode, потому что generator в показанном сценарии охватывает каждый code point.

Вопрос 5 из 30

Какой рефакторинг делает поведение «Реальная транзакция order/outbox» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
@Test fun repository_commits_order_and_outbox() = withDatabaseContainer {
    val id = service.place(command)
    assertNotNull(orderTable.find(id))
    assertEquals(1, outboxTable.countFor(id))
}

Накатывать те же migrations, изолировать тест транзакцией/схемой и проверять failure path с rollback. Добавить защитную проверку перед фрагментом, поскольку он не требует очистки данных между сценариями. Добавить локальную обработку результата, потому что контейнер автоматически моделирует сбой сети и failover кластера. Сохранить API и считать достаточным условие: Unit fake не может хранить два объекта, поэтому только контейнер проверяет значения. Спрятать участок за вспомогательной функцией, сохранив предположение: Такой тест заменяет нагрузочное тестирование и backup restore.

Вопрос 6 из 30

Какой соседний случай отличает устойчивое решение «Сигналы качества в CI» от удачного примера?

Добавить тест на состояние, при котором покрытие 100% означает отсутствие дефектов и ненужность code review. Проверить соседний случай: Низкое покрытие в показанном сценарии хуже, даже если непокрыт сгенерированный glue. Считать опасной границей ситуацию, где mutation score и line coverage являются одним показателем. Coverage может не учитывать generated/inlined coroutine-код ожидаемым образом; сравнивать тренд полезнее абсолютной цифры. Отдельно проверить предположение, что покрытие измеряет корректность конкурентного расписания.

Вопрос 7 из 30

Как сделать unit-тест детерминированным?

// Проследите фактическое выполнение без изменения кода.
class Discount(private val clock: Clock) {
    fun apply(order: Order): Money = if (clock.today() in order.promoDays) order.total * 0.9 else order.total
}

Передать fake `Clock` с фиксированной датой и проверить границы `promoDays`. Мокировать Money multiplication, не проверяя условие скидки. Использовать LocalDate.now() и запускать тест только в нужный день. Добавить retry теста при несовпадении даты. Сравнивать только, что результат положительный.

Вопрос 8 из 30

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
@Test fun emits_after_delay() = runTest {
    val flow = flow { delay(1_000); emit(1) }
    val deferred = async { flow.first() }
    advanceTimeBy(999)
    assertFalse(deferred.isCompleted)
    advanceTimeBy(1)
    assertEquals(1, deferred.await())
}

`runTest` управляет test dispatchers и виртуальным временем, автоматически ожидая/проверяя дочерние корутины в своей области. Контракт здесь понимают так: Скорость реального Dispatchers.IO под нагрузкой. Наблюдаемое поведение выводят из того, что отсутствие любых утечек jobs после теста без завершения async. Объяснение опирается на утверждение: Что delay блокирует тестовый поток на 1000 мс. Причину поведения формулируют так: Точное соответствие виртуальной миллисекунды системному wall clock.

Вопрос 9 из 30

Какую точечную правку стоит принять на ревью фрагмента «Инвариант и генерация данных»?

// Сохраните назначение фрагмента, но укрепите его контракт.
class ReversePropertyTest : StringSpec({
    property("reverse twice") {
        checkAll<String> { s -> s.reversed().reversed() shouldBe s }
    }
})

Обернуть операцию проверкой и не менять основной контракт: Он гарантирует отсутствие дефектов в реализации reversed. Оставить реализацию без изменений и закрепить тестом предположение: Он математически доказывает свойство для всех возможных строк. Добавить доменные generators, граничные распределения и сохранять seed упавшего прогона для воспроизведения. Передать ответственность владельцу вызова, предполагая, что он проверяет только одну случайную строку без воспроизводимого seed. Оставить структуру прежней, документировав утверждение: Он заменяет тесты Unicode, потому что generator в показанном сценарии охватывает каждый code point.

Вопрос 10 из 30

Какой соседний случай отличает устойчивое решение «Реальная транзакция order/outbox» от удачного примера?

Проверить соседний случай: Unit fake не может хранить два объекта, поэтому только контейнер проверяет значения. Добавить регрессию на гипотезу: Такой тест заменяет нагрузочное тестирование и backup restore. Один контейнер в CI не воспроизводит настройки пула, репликацию и права production, поэтому нужны отдельные smoke/operational проверки. Считать опасной границей ситуацию, где он не требует очистки данных между сценариями. Добавить тест на состояние, при котором контейнер автоматически моделирует сбой сети и failover кластера.

Вопрос 11 из 30

Для «Сигналы качества в CI» предлагают правку: Задать пороги по модулям, разбирать выжившие мутации и не стимулировать пустые assertions ради числа. Какой компромисс нельзя пропустить?

Автоматические ворота предотвращают деградацию, но жёсткий единый порог провоцирует тесты без ценности. Главный риск формулируют так: Покрытие измеряет корректность конкурентного расписания. Цена упрощения проявится, если mutation score и line coverage являются одним показателем. Главная цена решения — необходимость учитывать, что покрытие 100% означает отсутствие дефектов и ненужность code review. Граница полезности решения описывается условием: Низкое покрытие в показанном сценарии хуже, даже если непокрыт сгенерированный glue.

Вопрос 12 из 30

Что нужно сделать для тестируемого жизненного цикла?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
class Worker(private val scope: CoroutineScope, private val queue: Queue) {
    fun start(): Job = scope.launch {
        queue.items.collect { process(it) }
    }
}

Тестовая очередь должна использовать Thread.sleep для каждого элемента. Возвращать Job не нужно: garbage collector остановит collector. Worker должен создавать GlobalScope внутри, чтобы тест не мог случайно отменить работу. Collect автоматически завершается после первого элемента. Дать scope явного владельца, возвращать Job и управлять очередью и отменой из теста.

Вопрос 13 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
@Test fun emits_after_delay() = runTest {
    val flow = flow { delay(1_000); emit(1) }
    val deferred = async { flow.first() }
    advanceTimeBy(999)
    assertFalse(deferred.isCompleted)
    advanceTimeBy(1)
    assertEquals(1, deferred.await())
}

Спрятать участок за вспомогательной функцией, сохранив предположение: Скорость реального Dispatchers.IO под нагрузкой. Перенести проверку в вызывающий код, исходя из того, что что delay блокирует тестовый поток на 1000 мс. Добавить защитную проверку перед фрагментом, поскольку точное соответствие виртуальной миллисекунды системному wall clock. Передавать тестируемому коду dispatcher/scope с тем же scheduler и не смешивать его с реальными глобальными пулами. Оставить реализацию без изменений и закрепить тестом предположение: Отсутствие любых утечек jobs после теста без завершения async.

Вопрос 14 из 30

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

Зафиксировать сценарий, где ожидается: Он математически доказывает свойство для всех возможных строк. Отдельно воспроизвести случай, в котором он гарантирует отсутствие дефектов в реализации reversed. Тривиальное свойство может пройти у неверной реализации; например, сравнение функции самой с собой ничего не доказывает. Воспроизвести редкий сценарий, где он проверяет только одну случайную строку без воспроизводимого seed. Добавить граничный тест на утверждение: Он заменяет тесты Unicode, потому что generator в показанном сценарии охватывает каждый code point.

Вопрос 15 из 30

Что станет новой точкой внимания после изменения «Реальная транзакция order/outbox»: Накатывать те же migrations, изолировать тест транзакцией/схемой и проверять failure path с rollback?

Реальная зависимость повышает достоверность, но замедляет suite; критические контракты оставляют здесь, комбинации логики — в unit. Новый риск связан с тем, что он не требует очистки данных между сценариями. Цена упрощения проявится, если unit fake не может хранить два объекта, поэтому только контейнер проверяет значения. После внедрения придётся исходить из того, что контейнер автоматически моделирует сбой сети и failover кластера. Компромисс состоит в утверждении: Такой тест заменяет нагрузочное тестирование и backup restore.

Вопрос 16 из 30

Как интерпретировать высокое покрытие строк?

// Проследите фактическое выполнение без изменения кода.
// build.gradle.kts
tasks.test {
    useJUnitPlatform()
    testLogging { events("failed", "skipped") }
}
// static analysis + coverage + mutation report in CI

Низкое покрытие в показанном сценарии хуже, даже если непокрыт сгенерированный glue. Покрытие 100% означает отсутствие дефектов и ненужность code review. Mutation score и line coverage являются одним показателем. Как карту выполненного кода, а не доказательство правильности тестов. Покрытие измеряет корректность конкурентного расписания.

Вопрос 17 из 30

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
class Worker(private val scope: CoroutineScope, private val queue: Queue) {
    fun start(): Job = scope.launch {
        queue.items.collect { process(it) }
    }
}

Причину поведения формулируют так: Тестовая очередь должна использовать Thread.sleep для каждого элемента. Поведение связывают с правилом: Worker должен создавать GlobalScope внутри, чтобы тест не мог случайно отменить работу. Объяснение опирается на утверждение: Collect автоматически завершается после первого элемента. Контракт здесь понимают так: Возвращать Job не нужно: garbage collector остановит collector. Конкурентный компонент тестируем, когда его scope, источники и политика остановки являются явными зависимостями/контрактами.

Вопрос 18 из 30

Какое объяснение результата «Внедрённые часы в unit-тесте» выдерживает проверку соседними случаями?

// На ревью требуется объяснить причину поведения.
class Discount(private val clock: Clock) {
    fun apply(order: Order): Money = if (clock.today() in order.promoDays) order.total * 0.9 else order.total
}

Семантика фрагмента приводит к тому, что сравнивать только, что результат положительный. Механика примера описывается утверждением: Добавить retry теста при несовпадении даты. Из правил языка или API следует, что использовать LocalDate.now() и запускать тест только в нужный день. Причина результата в том, что мокировать Money multiplication, не проверяя условие скидки. Unit test изолирует правило через управляемые зависимости и проверяет наблюдаемый контракт, а не приватные шаги.

Вопрос 19 из 30

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

Подход находит неожиданные края, но не заменяет конкретные сценарии, которые объясняют бизнес-требование. Граница полезности решения описывается условием: Он проверяет только одну случайную строку без воспроизводимого seed. После правки останется ограничение: Он заменяет тесты Unicode, потому что generator в показанном сценарии охватывает каждый code point. Главная цена решения — необходимость учитывать, что он гарантирует отсутствие дефектов в реализации reversed. Обратная сторона изменения состоит в том, что он математически доказывает свойство для всех возможных строк.

Вопрос 20 из 30

Почему реальный контейнер БД важнее in-memory замены?

// Проследите фактическое выполнение без изменения кода.
@Test fun repository_commits_order_and_outbox() = withDatabaseContainer {
    val id = service.place(command)
    assertNotNull(orderTable.find(id))
    assertEquals(1, outboxTable.countFor(id))
}

Он проверяет настоящий SQL-диалект, ограничения, транзакции и миграции. Он не требует очистки данных между сценариями. Контейнер автоматически моделирует сбой сети и failover кластера. Такой тест заменяет нагрузочное тестирование и backup restore. Unit fake не может хранить два объекта, поэтому только контейнер проверяет значения.

Вопрос 21 из 30

Какое правило определяет поведение фрагмента «Сигналы качества в CI»?

// На ревью требуется объяснить причину поведения.
// build.gradle.kts
tasks.test {
    useJUnitPlatform()
    testLogging { events("failed", "skipped") }
}
// static analysis + coverage + mutation report in CI

Инструменты дают разные сигналы: coverage — выполнение, static analysis — подозрительные конструкции, mutation — чувствительность тестов к изменению поведения. Причину поведения формулируют так: Mutation score и line coverage являются одним показателем. Семантика фрагмента приводит к тому, что низкое покрытие в показанном сценарии хуже, даже если непокрыт сгенерированный glue. Поведение связывают с правилом: Покрытие измеряет корректность конкурентного расписания. Причина результата в том, что покрытие 100% означает отсутствие дефектов и ненужность code review.

Вопрос 22 из 30

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
class Worker(private val scope: CoroutineScope, private val queue: Queue) {
    fun start(): Job = scope.launch {
        queue.items.collect { process(it) }
    }
}

Перенести проверку в вызывающий код, исходя из того, что collect автоматически завершается после первого элемента. Добавить защитную проверку перед фрагментом, поскольку тестовая очередь должна использовать Thread.sleep для каждого элемента. Спрятать участок за вспомогательной функцией, сохранив предположение: Возвращать Job не нужно: garbage collector остановит collector. Добавить идемпотентный start или запрет повторного запуска, обработку ошибки process и deterministic shutdown. Ограничиться поясняющим комментарием о том, что worker должен создавать GlobalScope внутри, чтобы тест не мог случайно отменить работу.

Вопрос 23 из 30

Какая небольшая правка заметно повышает надёжность «Внедрённые часы в unit-тесте»?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Discount(private val clock: Clock) {
    fun apply(order: Order): Money = if (clock.today() in order.promoDays) order.total * 0.9 else order.total
}

Передать ответственность владельцу вызова, предполагая, что использовать LocalDate.now() и запускать тест только в нужный день. Зафиксировать текущее поведение регрессионным тестом: Добавить retry теста при несовпадении даты. Добавить локальную обработку результата, потому что мокировать Money multiplication, не проверяя условие скидки. Сохранить API и считать достаточным условие: Сравнивать только, что результат положительный. Составить таблицу границ периода и оставить системный Clock только в рабочей среде adapter.

Вопрос 24 из 30

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

`advanceTimeBy` продвигает время, но иногда требуется `runCurrent` для задач, запланированных точно на текущий момент. Проверить границу полезности утверждения: Что delay блокирует тестовый поток на 1000 мс. Добавить граничный тест на утверждение: Скорость реального Dispatchers.IO под нагрузкой. Воспроизвести редкий сценарий, где точное соответствие виртуальной миллисекунды системному wall clock. Добавить тест на состояние, при котором отсутствие любых утечек jobs после теста без завершения async.

Вопрос 25 из 30

Какое утверждение точнее всего объясняет поведение фрагмента «Реальная транзакция order/outbox»?

// На ревью требуется объяснить причину поведения.
@Test fun repository_commits_order_and_outbox() = withDatabaseContainer {
    val id = service.place(command)
    assertNotNull(orderTable.find(id))
    assertEquals(1, outboxTable.countFor(id))
}

Здесь действует следующее правило: Он не требует очистки данных между сценариями. Контракт здесь понимают так: Контейнер автоматически моделирует сбой сети и failover кластера. Причину поведения формулируют так: Unit fake не может хранить два объекта, поэтому только контейнер проверяет значения. Интеграционный тест проверяет границы между собственным кодом и реальной технологией; окружение должно быть максимально совместимо с production. Наблюдаемое поведение выводят из того, что такой тест заменяет нагрузочное тестирование и backup restore.

Вопрос 26 из 30

Какая правка устраняет причину риска в «Сигналы качества в CI», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
// build.gradle.kts
tasks.test {
    useJUnitPlatform()
    testLogging { events("failed", "skipped") }
}
// static analysis + coverage + mutation report in CI

Добавить защитную проверку перед фрагментом, поскольку низкое покрытие в показанном сценарии хуже, даже если непокрыт сгенерированный glue. Вынести участок в отдельный метод, считая верным следующее: Mutation score и line coverage являются одним показателем. Спрятать участок за вспомогательной функцией, сохранив предположение: Покрытие 100% означает отсутствие дефектов и ненужность code review. Задать пороги по модулям, разбирать выжившие мутации и не стимулировать пустые assertions ради числа. Перенести проверку в вызывающий код, исходя из того, что покрытие измеряет корректность конкурентного расписания.

Вопрос 27 из 30

Что проверить отдельно, чтобы не принять «Управляемый lifecycle worker» за универсальное правило?

Проверить, сохраняется ли контракт, когда тестовая очередь должна использовать Thread.sleep для каждого элемента. Зафиксировать сценарий, где ожидается: Возвращать Job не нужно: garbage collector остановит collector. Добавить граничный тест на утверждение: Collect автоматически завершается после первого элемента. Два вызова start могут создать два consumer и дублировать обработку, если компонент не определяет эту ситуацию. Проверить крайний ввод, при котором worker должен создавать GlobalScope внутри, чтобы тест не мог случайно отменить работу.

Вопрос 28 из 30

Какой соседний случай отличает устойчивое решение «Внедрённые часы в unit-тесте» от удачного примера?

Считать опасной границей ситуацию, где сравнивать только, что результат положительный. Отдельно проверить предположение, что добавить retry теста при несовпадении даты. Фиксированная дата без timezone-контракта может не воспроизвести переход дня для пользователя в другой зоне. Добавить регрессию на гипотезу: Мокировать Money multiplication, не проверяя условие скидки. Проверить соседний случай: Использовать LocalDate.now() и запускать тест только в нужный день.

Вопрос 29 из 30

Команда собирается передавать тестируемому коду dispatcher/scope с тем же scheduler и не смешивать его с реальными глобальными пулами. Что придётся учитывать после внедрения в «Граница виртуальной задержки»?

После внедрения придётся исходить из того, что отсутствие любых утечек jobs после теста без завершения async. Граница полезности решения описывается условием: Точное соответствие виртуальной миллисекунды системному wall clock. После правки останется ограничение: Скорость реального Dispatchers.IO под нагрузкой. Виртуальное время устраняет медленные/flaky задержки, но не измеряет производительность и поведение реального executor. Главный риск формулируют так: Что delay блокирует тестовый поток на 1000 мс.

Вопрос 30 из 30

Чем такой тест полезнее нескольких примеров?

// Проследите фактическое выполнение без изменения кода.
class ReversePropertyTest : StringSpec({
    property("reverse twice") {
        checkAll<String> { s -> s.reversed().reversed() shouldBe s }
    }
})

Он гарантирует отсутствие дефектов в реализации reversed. Он заменяет тесты Unicode, потому что generator в показанном сценарии охватывает каждый code point. Он проверяет только одну случайную строку без воспроизводимого seed. Он проверяет инвариант на множестве сгенерированных строк и при сбое обычно уменьшает контрпример до простого. Он математически доказывает свойство для всех возможных строк.