Мінімальний тестовий baseline для Boot-шаблону

1. «У мене ж запускається!» — тимчасове перемир’я

Є дуже людське відчуття: якщо застосунок один раз запустився в IDE, значить «ну воно працює». І це відчуття логічне — мозок любить закривати задачі й іти пити чай. Але Spring Boot — це така штука, де більша частина реальної роботи відбувається на старті: він збирає контекст, пов’язує конфігурацію, піднімає інфраструктуру, запускає вбудований сервер і лише потім дає вам нормальне середовище виконання. Помилка може ховатися у wiring або конфігу, а проявитися «раптово» — у найнезручніший момент.

Уявіть, що catalog-service — це не просто набір класів, а зібрана система, у якої є «ритуал запуску». Ритуал не магічний — просто довгий. І якщо ви змінюєте щось в одному місці, наприклад додаєте параметр у конструктор сервісу, зламатися може старт, а не той фрагмент функціональності, який ви чіпали.

Ось типовий сюжет без тестів:

flowchart TD
    A[Ви змінили код або YAML] --> B[Запустили в IDE один раз]
    B --> C{Запустилося?}
    C -->|Так| D[Упевненість: усе гаразд]
    C -->|Ні| E[Витратили 30 хвилин на пошук причини]
    D --> F[Через день ще один рефакторинг]
    F --> G[Раптово перестало стартувати]

Із тестами сценарій стає нуднішим, а це комплімент інженерії:

flowchart TD
    A[Ви змінили код або YAML] --> B[Запустили тести]
    B --> C{Контекст піднявся?}
    C -->|Так| D[Йдемо далі спокійно]
    C -->|Ні| E[Помилка одразу видна: де й чому]

Ідея сьогоднішньої лекції проста: ми хочемо впіймати момент, коли старт ламається, якнайраніше, поки ви ще пам’ятаєте, що змінювали. Не через годину. Не після збирання jar. Не після того, як ви вже встигли звинуватити Tomcat, Jackson, Gradle і долю. А відразу.

2. Minimal test baseline: зміст і межі

Коли початківець чує «додамо тести», у нього часто вмикається режим паніки: «Мені тепер потрібно покрити тестами весь проєкт? А як тестувати Spring? А де мокати світ?». Спокійно: сьогодні ми робимо не «велику піраміду тестування», а найпростіший страхувальний шар, який доводить одну важливу річ: наш Boot-сервіс збирається.

У цьому курсі catalog-service — це шаблон. У шаблону є мінімальна відповідальність: стартувати передбачувано. Тому minimal baseline — це набір перевірок, які стримують регресії саме в старті та збиранні контексту.

Щоб не плутатися в термінології, давайте чесно зафіксуємо зміст слова smoke-test у нашому контексті. Smoke-test — це «швидка перевірка, що двигун узагалі заводиться». Він не доводить, що машина проїде 1000 км, але рятує від ситуації «ми забули прикрутити колеса».

Нижче — дуже приземлена таблиця, яка зазвичай знімає зайве напруження:

Важливий нюанс: minimal baseline не зобов’язаний бути великим. Ба більше, якщо ви зробите його величезним, він перестане бути «мінімальним» і почне гальмувати розробку. Наша мета — корисний захист із мінімальною ціною.

3. Smoke-тести старту для Boot-проєктів

Тут є невеликий парадокс. Spring Boot створений, щоб «спрощувати старт і збирання застосунку», але при цьому новачку найпростіше випадково зламати саме старт. Причина не в тому, що Boot крихкий. Причина в тому, що Boot бере на себе багато роботи зі збирання, а ви працюєте на рівні «об’єктів і анотацій». Ви змінили один об’єкт — а ефект сплив на етапі збирання всієї системи.

Якщо говорити простими словами, Boot-проєкт часто ламається в трьох місцях.

Перше місце — DI та wiring. Ви додаєте залежність у конструктор, і все. Якщо бін не зареєстрований, контекст не підніметься. Java-компілятор тут не врятує: код компілюється, але система «не зібралася».

Друге місце — конфігурація. У нас уже є @ConfigurationProperties, immutable-модель і валідація. Це чудово, але за це є чесна ціна: зламана конфігурація валить старт. І це правильно (fail-fast), але це означає, що конфігурацію теж потрібно перевіряти.

Третє місце — логіка запуску. Навіть акуратний StartupSummaryRunner може залежати від конфігурації або сервісів. Помилка там часто проявляється ще до того, як ви встигнете звернутися хоча б до однієї кінцевої точки.

І ось тут smoke-test працює як «детектор того, що проєкт перестав бути Boot-застосунком». Він не розумніший за вас, він просто дисциплінованіший: піднімає контекст щоразу й чесно падає, якщо збирання неможливе. На цьому місці нам поки не потрібна конкретна анотація і докладна механіка. Важливо побачити сам клас проблем: Boot-проєкт часто ламається саме в збиранні застосунку.

4. Історія: як зламати старт без «функціоналу»

Зазвичай старт ламають не зі злим наміром, а дуже буденно. Наприклад, ви вирішили, що сервісу треба «вміти експортувати каталог» (хай навіть просто для внутрішньої діагностики). Ви додали нову залежність у CourseCatalogService, бо так виглядає «чиста архітектура»: сервіс використовує експортер, експортер робить експорт. Гарно? Гарно. А тепер ключовий момент: якщо ви забули зареєструвати бін експортера — сервіс не стартує взагалі.

Ось мінімальний приклад, близький до реальності, і дуже схожий на те, що студенти роблять автоматично:

import org.springframework.stereotype.Service;

// Контракт експортера: сервіс хоче «щось», що вміє експортувати каталог.
interface CatalogExporter {
    void export();
}

@Service
class CourseCatalogService {

    private final CatalogExporter exporter;

    // ВАЖЛИВО: якщо реалізацію CatalogExporter не зареєстровано як Spring-бін,
    // то старт контексту впаде на етапі wiring/DI.
    CourseCatalogService(CatalogExporter exporter) {
        this.exporter = exporter;
    }
}

Код компілюється. IDE задоволена. А застосунок на старті скаже приблизно таке людською мовою: «Ти попросив мене створити CourseCatalogService, але я не знаю, звідки взяти CatalogExporter».

І ось тут важливо зрозуміти сенс тестів. Ми не хочемо ловити цю помилку випадково, коли ви вже переключилися на іншу задачу. Ми хочемо, щоб вона спливла відразу після зміни — у вигляді червоного тесту, який говорить: «Контекст не піднімається. Винуватий wiring».

5. Практика minimal baseline

Що ми “страхуємо” в catalog-service

Коли ми говоримо «мінімальний test baseline», корисно подумки відділити два шари: що тести дають зараз і чого вони не обіцяють.

Зараз вони дають просту гарантію: сервіс здатний стартувати як Boot-застосунок за очікуваної конфігурації. Це охоплює створення контексту, реєстрацію бінів, binding конфігурації та виконання валідації.

Зараз вони не обіцяють, що кожна кінцева точка endpoint повертає ідеальний JSON, що фільтри працюють по всіх гілках, що Actuator віддає потрібні поля або що логування красиве. Це все хороші теми, але в кожної з них є своя ціна. Сьогоднішня ціна має бути маленькою.

Нижче — схема, яку зручно тримати в голові:

flowchart TD
    A[Minimal baseline] --> B[Контекст піднімається]
    A --> C[Конфігурація зв’язується і валідовується]
    A --> D[Ключові біни доступні]
    A -.-> E["Не перевіряємо докладно web-відповіді"]
    A -.-> F["Не перевіряємо «всі сценарії» каталогу"]
    A -.-> G[Не будуємо інфраструктуру для складних тестів]

Тобто ми робимо «страхування старту», а не «повний судовий процес над застосунком».

Smoke-check старту контексту

У minimal baseline майже завжди є один найдешевший smoke-check: він змушує Boot щоразу заново пройти шлях старту й одразу показує, чи зібрався застосунок як система. Ззовні така перевірка може виглядати майже порожньою, але цінність тут не в кількості assertions, а в самому факті контрольованого старту.

Тут важливо відокремити два рівні. Перше питання — «контекст узагалі піднімається?». Друге — «чи доступний конкретний бін, чи застосувався override властивості, чи забіндився потрібний properties-клас?». Для шаблону спочатку потрібен саме перший рівень: хоча б базова сигналізація про зламаний старт.

Тести як частина шаблону: handoff-мислення

У нас курс не про «написали код і розійшлися», а про «зібрали повторно використовуваний шаблон». Шаблон — це те, що ви будете копіювати, розвивати, передавати іншому розробнику, приносити в наступний проєкт і розширювати. І ось тут тести стають не розкішшю, а частиною упаковки.

Якщо у вас немає тестів, ваш шаблон схожий на валізу без замка: зовні все акуратно, але варто трохи потрясти — і речі розлітаються по аеропорту. Якщо тести є, ви можете робити зміни сміливіше: додавати нові біни, перебудовувати конфіг, рефакторити пакети. Бо у вас є «сигналізація», яка кричить відразу, а не через тиждень.

Інженерна цінність тестів у шаблоні — у тому, що вони фіксують «мінімальну живучість». Це як перевірити, що електрика вмикається і запобіжники на місці. Так, це ще не гарантія, що чайник смачно кип’ятить воду, але без цього ви взагалі не п’єте чай.

Ручний запуск як альтернатива

Часто здається, що тести не потрібні, якщо ви дисципліновано перезапускаєте застосунок після кожної зміни. В ідеальному світі це могло б працювати. У реальному світі це зазвичай натрапляє на три речі.

Перша — людина не робот. Ви втомлюєтеся, відволікаєтеся, забуваєте. Це нормально.

Друга — у Boot-проєкті один запуск може займати помітний час, і ви починаєте економити перезапуски. «Та я лише коментар змінив…» — і потім виявляється, що разом із коментарем ви випадково зачепили конфіг або імпорт.

Третя — ручний запуск не залишає слідів. Він не документує, що ви перевіряли. Тест документує: «ми вважаємо нормою, що застосунок стартує». І це важливо навіть якщо ви працюєте самі. Особливо якщо ви працюєте самі: ніхто не прийде і не скаже «ти забув перевірити старт».

Тому тести — це не про недовіру до себе. Це про повагу до свого майбутнього «я», яке розбиратиметься з проєктом через місяць.

6. Типові помилки під час додавання test baseline

Помилка № 1: «Це ж Boot-курс, а не тестування, отже тести можна не писати».
Ця думка звучить логічно, доки ви не впіймаєте свою першу регресію старту через маленьку зміну в конструкторі або YAML. Мінімальні smoke-тести — це не «професія тестувальника», а ремінь безпеки для розробника. Їхнє завдання — не покрити все, а просто не дати проєкту тихо перестати стартувати.

Помилка № 2: обмежуватися лише ручним запуском з IDE і вважати це достатньою перевіркою.
IDE справді робить життя простішим, але вона ж іноді й «пом’якшує» реальність: кеш, автоматичні перезапуски, ваші локальні налаштування, випадково активний профіль. Тест запускається завжди однаково й не залежить від того, у якому ви настрої та скільки у вас відкрито вкладок.

Помилка № 3: спробувати відразу тестувати весь функціонал catalog-service «як у справжньому проєкті».
Бажання зрозуміле: раз уже прийшли тести, давайте накриємо ними все. Але це швидко перетворює базовий шар на важку систему, яку лінь запускати. Мінімальний baseline має залишатися мінімальним: перевірка старту та збирання контексту — і все, без спроби довести через один тест, що ви вже готові до production.

Помилка № 4: змішувати в одному тесті перевірку старту, прикладну логіку та «заодно ще один кейс».
Такий тест починає ламатися з будь-якого приводу, а ви перестаєте розуміти, що саме він перевіряє. Smoke-test хороший тим, що в нього зрозуміла мета: контекст піднявся чи ні. Чим вужча мета, тим менше загадок у налагодженні.

Помилка № 5: думати, що «порожній тест» — це фікція і він нічого не дає.
У світі Spring Boot «порожній метод» під @SpringBootTest — це не порожнеча, а перевірка старту, яка відбувається до входу в метод. Якщо контекст не піднявся — тест чесно червоний. Іноді це найважливіша перевірка в проєкті, бо без старту у вас немає взагалі нічого: ні endpoint’ів, ні JSON, ні Actuator, ні «ну я ж майже дописав».