Підсумки

Висновки

Шлях лише описує розташування файла, а відносний шлях залежить від робочої теки процесу, тому вхідні й вихідні шляхи краще передавати аргументами. Текст зберігається як байти в конкретному кодуванні, а use і useLines закривають ресурс після завершення блоку навіть під час винятку. Помилки введення-виведення обробляють точно, а важливий файл оновлюють через повністю записаний тимчасовий файл і перейменування з явною політикою атомарності. CSV має власний контракт формату, тому split підходить лише для свідомо обмеженого варіанта з перевіркою всіх рядків. Плагін kotlinx.serialization генерує серіалізатори для класів з @Serializable, а налаштування Json визначають схему, значення за замовчуванням і реакцію на невідомі поля. Sealed-ієрархія з дискримінатором задає поліморфне кодування, а тип без вбудованої підтримки, як-от LocalDate, потребує власного серіалізатора. Модульний тест є виконуваним контрактом зі структурою Arrange–Act–Assert і незалежно визначеним очікуваним значенням. Звіт Gradle і покриття показують, що виконано, але правильність доводять перевірки поведінки, меж і пошкоджених даних.

Питання для самоперевірки

1. Від чого залежить відносний шлях?
2. Чому перевірка exists не замінює обробку IOException?
3. Чим байти відрізняються від String.length?
4. Чому не можна повертати Sequence із useLines?
5. Які гарантії дає й не дає ATOMIC_MOVE?
6. Чому split не є загальним CSV-парсером?
7. Навіщо serialization має і плагін, і runtime?
8. Коли ignoreUnknownKeys приховує помилку?
9. Який тип визначає поліморфний серіалізатор?
10. Навіщо LocalDate потрібне явно визначене подання?
11. Які ролі мають kotlin.test, Platform і Jupiter?
12. Чому покриття не доводить правильність?

Корисні посилання

• https://kotlinlang.org/docs/serialization.html.
• https://github.com/Kotlin/kotlinx.serialization/releases/tag/v1.11.0.
• https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.io.path/.
• https://kotlinlang.org/docs/jvm-test-using-junit.html.
• https://docs.junit.org/.