Flow и реактивные потоки — бесплатный тест онлайн

Вопрос 1 из 25

Что добавить в регрессионный набор для «Виртуальный debounce»?

Добавить регрессию на гипотезу: Мокировать debounce так, чтобы он возвращал исходный поток. Проверить соседний случай: Использовать Thread.sleep(301) между каждым вводом и надеяться на планировщик. Проверить крайний ввод, при котором собрать Flow без ограничения и завершить тест по таймауту. Отдельно проверить предположение, что проверить только тип возвращаемого Flow, не собирая его. Если оператор использует dispatcher с другим scheduler, advanceTimeBy не управляет его задачами и тест становится недетерминированным.

Вопрос 2 из 25

Что станет новой точкой внимания после изменения «Две коллекции cold Flow»: Если источник дорогой и должен быть общим, явно преобразовать его через `shareIn`/`stateIn` в scope с понятным жизненным циклом?

Cold-семантика изолирует потребителей и упрощает композицию, но дублирует дорогую работу без sharing. После внедрения придётся исходить из того, что один раз, потому что Flow кэширует первую коллекцию. Цена упрощения проявится, если ни разу, потому что builder выполняется при создании до runBlocking. Компромисс состоит в утверждении: Вторая коллекция завершится ошибкой одноразового потока. Практическое ограничение подхода: Три раза: один при создании и по одному на collector.

Вопрос 3 из 25

Какие значения будут напечатаны?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    (1..5).asFlow().map { it * 2 }.filter { it > 5 }.take(2)
        .collect { print("$it ") }
}

Будут выведены `6 8`: `map` удвоит числа, `filter` оставит значения больше 5. Будут напечатаны `3 4`, потому что filter применяется до map. Будут напечатаны `6 8 10`, так как take не влияет на upstream. Код не компилируется: take доступен только коллекциям. Будут напечатаны `2 4`, поскольку take выполняется первым.

Вопрос 4 из 25

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val state = MutableStateFlow(0)
    state.value = 1
    state.value = 1
    println(state.value)
}

Ключевым считают контракт: Будет выведено `0`, пока не появится collector. Такой результат объясняют тем, что каждый subscriber получит всю историю 0,1,1. Наблюдаемое поведение выводят из того, что будет выведено `2`, потому что value считает число присваиваний. Из правил языка или API следует, что код не компилируется: StateFlow нельзя менять напрямую. StateFlow — горячее состояние с текущим значением и conflation по `equals`; новый подписчик сразу получает актуальное значение.

Вопрос 5 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val events = MutableSharedFlow<Int>(replay = 1)
    events.emit(7)
    println(events.replayCache)
}

Перенести проверку в вызывающий код, исходя из того, что будет выведено `[1]`, то есть размер replay вместо значения. Добавить защитную проверку перед фрагментом, поскольку будет выведено `[]`, потому что без подписчика emit в показанном сценарии отбрасывается. Вынести участок в отдельный метод, считая верным следующее: Код зависнет: SharedFlow требует активного collector для любого emit. Выбирать replay по семантике: 0 для неповторяемых сигналов, 1+ для значений, которые действительно можно повторить новому потребителю. Оставить структуру прежней, документировав утверждение: Будет выведено `[7, 7]`, потому что значение записывается и в буфер, и в cache.

Вопрос 6 из 25

Сколько раз появится `start`?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun numbers() = flow { println("start"); emit(1); emit(2) }
fun main() = runBlocking {
    val f = numbers()
    f.collect { print(it) }
    f.collect { print(it) }
}

Два раза: cold Flow запускает builder заново для каждого коллектора. Ни разу, потому что builder выполняется при создании до runBlocking. Три раза: один при создании и по одному на collector. Вторая коллекция завершится ошибкой одноразового потока. Один раз, потому что Flow кэширует первую коллекцию.

Вопрос 7 из 25

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    (1..5).asFlow().map { it * 2 }.filter { it > 5 }.take(2)
        .collect { print("$it ") }
}

Такой результат объясняют тем, что будут напечатаны `3 4`, потому что filter применяется до map. Из правил языка или API следует, что будут напечатаны `6 8 10`, так как take не влияет на upstream. Механика примера описывается утверждением: Будут напечатаны `2 4`, поскольку take выполняется первым. Причина результата в том, что код не компилируется: take доступен только коллекциям. Промежуточные операторы строят новый Flow; terminal collect запускает цепочку, а ограничивающие операторы отменяют upstream штатным механизмом.

Вопрос 8 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val state = MutableStateFlow(0)
    state.value = 1
    state.value = 1
    println(state.value)
}

Зафиксировать текущее поведение регрессионным тестом: Будет выведено `2`, потому что value считает число присваиваний. Добавить локальную обработку результата, потому что будет выведено `0`, пока не появится collector. Сохранить API и считать достаточным условие: Каждый subscriber получит всю историю 0,1,1. Обновлять сложное состояние через `update` и использовать устойчивые value-модели, а одноразовые события не кодировать повторным StateFlow-значением. Ограничиться поясняющим комментарием о том, что код не компилируется: StateFlow нельзя менять напрямую.

Вопрос 9 из 25

Где упрощённое объяснение «Replay горячего потока» перестаёт работать?

Воспроизвести редкий сценарий, где будет выведено `[1]`, то есть размер replay вместо значения. Событие навигации с replay=1 может повториться после пересоздания collector, если подтверждение потребления не моделируется отдельно. Проверить границу полезности утверждения: Код зависнет: SharedFlow требует активного collector для любого emit. Добавить граничный тест на утверждение: Будет выведено `[]`, потому что без подписчика emit в показанном сценарии отбрасывается. Добавить тест на состояние, при котором будет выведено `[7, 7]`, потому что значение записывается и в буфер, и в cache.

Вопрос 10 из 25

Предложенная правка для «Виртуальный debounce» звучит так: Ограничить сбор ожидаемым числом элементов через take или библиотеку проверки потоков и завершить созданные jobs. Какой недостаток важнее обсудить?

Сопровождение усложнится, если окажется, что проверить только тип возвращаемого Flow, не собирая его. Виртуальное время проверяет логику быстро, но отдельный интеграционный тест нужен для реального ввода, lifecycle и сетевой отмены. Граница полезности решения описывается условием: Собрать Flow без ограничения и завершить тест по таймауту. Главная цена решения — необходимость учитывать, что мокировать debounce так, чтобы он возвращал исходный поток. Обратная сторона изменения состоит в том, что использовать Thread.sleep(301) между каждым вводом и надеяться на планировщик.

Вопрос 11 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    (1..5).asFlow().map { it * 2 }.filter { it > 5 }.take(2)
        .collect { print("$it ") }
}

Добавить локальную обработку результата, потому что будут напечатаны `2 4`, поскольку take выполняется первым. Зафиксировать текущее поведение регрессионным тестом: Будут напечатаны `6 8 10`, так как take не влияет на upstream. Ограничиться поясняющим комментарием о том, что код не компилируется: take доступен только коллекциям. Располагать дешёвую фильтрацию до тяжёлого преобразования, если это не меняет смысл, и измерять буферизацию отдельно. Передать ответственность владельцу вызова, предполагая, что будут напечатаны `3 4`, потому что filter применяется до map.

Вопрос 12 из 25

Где поведение «Conflation одинакового состояния» требует отдельной проверки?

Проверить границу полезности утверждения: Будет выведено `2`, потому что value считает число присваиваний. Мутация объекта внутри того же экземпляра может не вызвать наблюдаемое новое значение, если ссылка и equals не изменились. Отдельно проверить предположение, что код не компилируется: StateFlow нельзя менять напрямую. Проверить соседний случай: Каждый subscriber получит всю историю 0,1,1. Добавить тест на состояние, при котором будет выведено `0`, пока не появится collector.

Вопрос 13 из 25

Предложенная правка для «Replay горячего потока» звучит так: Выбирать replay по семантике: 0 для неповторяемых сигналов, 1+ для значений, которые действительно можно повторить новому потребителю. Какой недостаток важнее обсудить?

Один источник эффективно обслуживает многих подписчиков, но потеря и повтор событий зависят от тонкой настройки буфера. Сопровождение усложнится, если окажется, что будет выведено `[]`, потому что без подписчика emit в показанном сценарии отбрасывается. Граница полезности решения описывается условием: Будет выведено `[7, 7]`, потому что значение записывается и в буфер, и в cache. Главная цена решения — необходимость учитывать, что код зависнет: SharedFlow требует активного collector для любого emit. После правки останется ограничение: Будет выведено `[1]`, то есть размер replay вместо значения.

Вопрос 14 из 25

Как проверить debounce и отмену `mapLatest` детерминированно?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.flow.*
fun search(queries: Flow<String>): Flow<String> = queries
    .debounce(300)
    .distinctUntilChanged()
    .mapLatest { "result:$it" }

Собрать Flow без ограничения и завершить тест по таймауту. Использовать `runTest` и общий `TestCoroutineScheduler`, продвигая время вокруг порога debounce. Мокировать debounce так, чтобы он возвращал исходный поток. Использовать Thread.sleep(301) между каждым вводом и надеяться на планировщик. Проверить только тип возвращаемого Flow, не собирая его.

Вопрос 15 из 25

Какое правило определяет поведение фрагмента «Две коллекции cold Flow»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun numbers() = flow { println("start"); emit(1); emit(2) }
fun main() = runBlocking {
    val f = numbers()
    f.collect { print(it) }
    f.collect { print(it) }
}

Причину поведения формулируют так: Вторая коллекция завершится ошибкой одноразового потока. Cold Flow описывает вычисление; выполнение начинается при collect и обычно создаётся заново для каждого коллектора. Контракт здесь понимают так: Три раза: один при создании и по одному на collector. Семантика фрагмента приводит к тому, что ни разу, потому что builder выполняется при создании до runBlocking. Причина результата в том, что один раз, потому что Flow кэширует первую коллекцию.

Вопрос 16 из 25

Что станет новой точкой внимания после изменения «Conflation одинакового состояния»: Обновлять сложное состояние через `update` и использовать устойчивые value-модели, а одноразовые события не кодировать повторным StateFlow-значением?

Практическое ограничение подхода: Каждый subscriber получит всю историю 0,1,1. После внедрения придётся исходить из того, что будет выведено `2`, потому что value считает число присваиваний. Новый риск связан с тем, что код не компилируется: StateFlow нельзя менять напрямую. Цена упрощения проявится, если будет выведено `0`, пока не появится collector. Текущее состояние удобно для интерфейс и поздних подписчиков, но не хранит очередь каждого промежуточного изменения.

Вопрос 17 из 25

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

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val events = MutableSharedFlow<Int>(replay = 1)
    events.emit(7)
    println(events.replayCache)
}

Будет выведено `[]`, потому что без подписчика emit в показанном сценарии отбрасывается. Будет выведено `[7]`: replay=1 сохраняет последнее значение для новых подписчиков и в replayCache. Будет выведено `[7, 7]`, потому что значение записывается и в буфер, и в cache. Код зависнет: SharedFlow требует активного collector для любого emit. Будет выведено `[1]`, то есть размер replay вместо значения.

Вопрос 18 из 25

На какой контракт языка или библиотеки опирается «Виртуальный debounce»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.flow.*
fun search(queries: Flow<String>): Flow<String> = queries
    .debounce(300)
    .distinctUntilChanged()
    .mapLatest { "result:$it" }

Контракт здесь понимают так: Использовать Thread.sleep(301) между каждым вводом и надеяться на планировщик. Причину поведения формулируют так: Проверить только тип возвращаемого Flow, не собирая его. Объяснение опирается на утверждение: Мокировать debounce так, чтобы он возвращал исходный поток. Flow с операторами времени тестируют виртуальным временем и контролируемым сборщиком; горячий источник и collector запускают в test scope. Наблюдаемое поведение выводят из того, что собрать Flow без ограничения и завершить тест по таймауту.

Вопрос 19 из 25

Как укрепить «Две коллекции cold Flow», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun numbers() = flow { println("start"); emit(1); emit(2) }
fun main() = runBlocking {
    val f = numbers()
    f.collect { print(it) }
    f.collect { print(it) }
}

Вынести участок в отдельный метод, считая верным следующее: Три раза: один при создании и по одному на collector. Оставить реализацию без изменений и закрепить тестом предположение: Ни разу, потому что builder выполняется при создании до runBlocking. Если источник дорогой и должен быть общим, явно преобразовать его через `shareIn`/`stateIn` в scope с понятным жизненным циклом. Оставить структуру прежней, документировав утверждение: Вторая коллекция завершится ошибкой одноразового потока. Добавить защитную проверку перед фрагментом, поскольку один раз, потому что Flow кэширует первую коллекцию.

Вопрос 20 из 25

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

`catch` перехватывает ошибки upstream, но не исключение, брошенное ниже него в collector или последующем операторе. Проверить, сохраняется ли контракт, когда будут напечатаны `6 8 10`, так как take не влияет на upstream. Отдельно воспроизвести случай, в котором будут напечатаны `2 4`, поскольку take выполняется первым. Воспроизвести редкий сценарий, где код не компилируется: take доступен только коллекциям. Зафиксировать сценарий, где ожидается: Будут напечатаны `3 4`, потому что filter применяется до map.

Вопрос 21 из 25

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

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val events = MutableSharedFlow<Int>(replay = 1)
    events.emit(7)
    println(events.replayCache)
}

SharedFlow — горячая рассылка; replay и дополнительный буфер определяют, что увидит поздний или медленный подписчик. Причина результата в том, что будет выведено `[1]`, то есть размер replay вместо значения. Механика примера описывается утверждением: Будет выведено `[]`, потому что без подписчика emit в показанном сценарии отбрасывается. Семантика фрагмента приводит к тому, что код зависнет: SharedFlow требует активного collector для любого emit. Контракт здесь понимают так: Будет выведено `[7, 7]`, потому что значение записывается и в буфер, и в cache.

Вопрос 22 из 25

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

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.flow.*
fun search(queries: Flow<String>): Flow<String> = queries
    .debounce(300)
    .distinctUntilChanged()
    .mapLatest { "result:$it" }

Ограничить сбор ожидаемым числом элементов через take или библиотеку проверки потоков и завершить созданные jobs. Добавить защитную проверку перед фрагментом, поскольку проверить только тип возвращаемого Flow, не собирая его. Спрятать участок за вспомогательной функцией, сохранив предположение: Использовать Thread.sleep(301) между каждым вводом и надеяться на планировщик. Оставить реализацию без изменений и закрепить тестом предположение: Собрать Flow без ограничения и завершить тест по таймауту. Перенести проверку в вызывающий код, исходя из того, что мокировать debounce так, чтобы он возвращал исходный поток.

Вопрос 23 из 25

Что проверить отдельно, чтобы не принять «Две коллекции cold Flow» за универсальное правило?

Повторная коллекция может повторить сетевой запрос или побочный эффект, даже если переменная Flow одна и та же. Добавить граничный тест на утверждение: Три раза: один при создании и по одному на collector. Отдельно воспроизвести случай, в котором вторая коллекция завершится ошибкой одноразового потока. Зафиксировать сценарий, где ожидается: Один раз, потому что Flow кэширует первую коллекцию. Проверить, сохраняется ли контракт, когда ни разу, потому что builder выполняется при создании до runBlocking.

Вопрос 24 из 25

В «Порядок операторов Flow» выбрали решение: Располагать дешёвую фильтрацию до тяжёлого преобразования, если это не меняет смысл, и измерять буферизацию отдельно. Какова его реальная цена?

Главная цена решения — необходимость учитывать, что будут напечатаны `6 8 10`, так как take не влияет на upstream. Главный риск формулируют так: Код не компилируется: take доступен только коллекциям. Сопровождение усложнится, если окажется, что будут напечатаны `3 4`, потому что filter применяется до map. Граница полезности решения описывается условием: Будут напечатаны `2 4`, поскольку take выполняется первым. Операторная цепочка выражает поток данных, но сложный порядок concurrency-операторов требует диаграммы и тестов времени.

Вопрос 25 из 25

Какое значение будет выведено и что важно для подписчиков?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun main() = runBlocking {
    val state = MutableStateFlow(0)
    state.value = 1
    state.value = 1
    println(state.value)
}

Будет выведено `0`, пока не появится collector. Будет выведено `2`, потому что value считает число присваиваний. Код не компилируется: StateFlow нельзя менять напрямую. Будет `1`; повторная запись равного значения не создаст нового состояния `StateFlow`. Каждый subscriber получит всю историю 0,1,1.