Лекція 142: Навіщо потрібна автоматизація збірки і тестування

Колись в епоху "до CI/CD" розробники вручну запускали тести, переносили файли між серверами й гадали, чому додаток, який "працював у мене на локалці", давав помилки в продакшені. Часи були непрості. Але, на щастя, програмісти не люблять відволікатися на нудну рутину. Тому, подумавши й застосувавши технології, вони придумали автоматизацію збірки й тестування. Тепер ми й інші розробники можемо витрачати наш час і зусилля на більш важливі задачі, замість того щоб шукати загублені ; або пробіли.

Автоматизація збірки й тестування — це фундаментальні кроки на шляху до CI/CD. Але навіщо воно все? Давай розбиратися.

Автоматизація збірки

Збірка (build) — це процес перетворення твого коду в готову програму, яку можна запустити. Для Java-додатків це зазвичай означає перетворення вихідних файлів .java у .class, а потім у фінальний .jar або .war файл.

Проблеми ручної збірки

Якщо у тебе невеликий проєкт, збирати вручну не така вже й велика проблема. Ну, частіше за все. Але уяви проєкт з сотнями класів, десятками модулів і купою залежностей. Ти кожного разу будете виконувати ті самі кроки? Це втрата часу! А помилки… Вони чатують на тебе за кожним кутом.

Навіщо потрібна автоматизація збірки?

Автоматизація збірки вирішує багато проблем:

1. Економія часу. Замість того щоб вручну запускати команди, ти налаштовуєш процес один раз, а система усе робить за тебе.
2. Повторюваність. Кожна збірка відбувається однаково, мінімізуючи ризик людських помилок.
3. Обробка залежностей. Інструменти збірки автоматично знаходять, завантажують і підключають потрібні бібліотеки.
4. Інтеграція з CI/CD пайплайнами. Системи типу Jenkins, GitLab CI або CircleCI можуть автоматично запускати збірку після кожної зміни коду.

Інструменти для автоматизації збірки

Розробники Java живуть як за кам'яною стіною, маючи кілька класних інструментів. Ти про них вже чув, і не раз.

• Maven — улюбленець корпоративного світу, який змушує тебе строго дотримуватись встановленого формату, але автоматизує все: від компіляції до генерації документації.
• Gradle — сучасна альтернатива Maven, яка дає більше гнучкості і краще працює з Kotlin.
• Ant — інструмент старої школи, який досі використовується, хоча потребує більше ручної конфігурації.

Приклад файлу pom.xml (Maven), який демонструє автоматизацію збірки:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>awesome-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.0.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>17</source>
                    <target>17</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Цей файл автоматично збирає проєкт, завантажує залежності й компілює код.

Автоматизація тестування

Тестування — це як контрольна закупівля, тільки в індустрії ПО. Ти перевіряєш, чи все працює так, як задумано, ще до того, як це побачать користувачі.

У Java ми звично говоримо про три основні типи тестів:

1. Юніт-тести — тестують окремі класи або методи.
2. Інтеграційні тести — перевіряють, як різні модулі працюють разом.
3. End-to-end (E2E) тести — тестують додаток повністю, включно з взаємодією з зовнішніми системами (наприклад, базою даних).

Навіщо автоматизувати тестування?

Ну, хоча б тому, що ручне тестування — той ще ад. Плюс воно повільне. Автотест зробить за хвилину те, що ручний тестувальник перевірятиме годинами. До того ж кожен автотест виконується однаково, виключаючи людський фактор. І ще: тести запускаються часто (наприклад, при кожному коміті), що дозволяє оперативно виправляти баги.

Інструменти для автоматизації тестування

У Java-інфраструктурі є купа інструментів:

• JUnit — основний інструмент для написання й запуску тестів.
• Mockito — бібліотека для створення моків і заглушок.
• Spring Boot Test — набір інструментів, інтегрований у Spring Boot, для тестування сервісів і контролерів.

Приклад простого юніт-тесту з використанням JUnit:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class CalculatorTest {

    @Test
    void testAddition() {
        Calculator calculator = new Calculator();
        int result = calculator.add(2, 3);
        assertEquals(5, result, "2 + 3 має дорівнювати 5");
    }
}

Інтеграція автоматичних кроків у CI/CD пайплайн

Автоматизація збірки й тестування чудово вписується в CI/CD:

1. Кожний коміт викликає пайплайн. Наприклад, розробник робить зміни, пушить їх у репозиторій, і пайплайн стартує автоматично.
2. Збірка запускається автоматично. Інструменти типу Jenkins запускають процес збірки і створюють артефакти.
3. Тести виконуються після збірки. Якщо знайдена проблема, пайплайн зупиняється, і розробник отримує повідомлення.

Приклад файлу .gitlab-ci.yml:

stages:
  - build
  - test

build:
  stage: build
  script:
    - mvn clean package

test:
  stage: test
  script:
    - mvn test

Тепер при будь-якому коміті GitLab CI автоматично запустить Maven збірку й тести.

Підсумковий приклад: від коду до продакшну

Як це виглядає на практиці:

1. Розробник пише новий код і пушить його в репозиторій.
2. CI/CD запускає пайплайн, який:
   • Збирає проєкт за допомогою Maven.
   • Виконує тести з JUnit.
   • Створює артефакт (наприклад, файл .jar).
   • Розгортає артефакт на тестову середу.

Якщо все пройшло успішно, зміни потрапляють у продакшн.

Переходимо до наступної лекції, де почнемо розбиратися з налаштуванням інструментів CI/CD, щоб усе це запрацювало як по маслу.