Тестування за допомогою Docker

Наш DevOps Богдан Нікітенко розповідає, як можна спростити процес тестування з використанням Docker, які основні команди для цього потрібно знати та які переваги тестування з Docker.

Почнемо одразу з технічних речей, які спрощує Docker:

• Dependency management: можна використовувати різні версії програм та їх різні конфігурації, а також використовувати одночасно декілька версій без додаткових утиліт.
• Знімаються обмеження на операційну систему (ОС): можна використовувати Windows і Мас OS для розробки й при цьому не потрібно тримати додаткових бінарників для виконання якоїсь дії. Достатньо самого Docker.
• Відкривається можливість значно підвищувати автоматизацію: прибрати рутинну роботу з проєкту.

При цьому поріг входження дуже низький — достатньо одного вечора або пари днів і можна вже відчути переваги використання Docker. Тому Docker — це просто. Він також відкриває доступ до цілого ряду корисних розробок — існує багато готових Docker images для різних програм. Зазвичай розвертати програму з використанням Docker набагато простіше, ніж конфігурити його з бінарників і т.д.

Docker використовується все більше і більше. Відсутність практики його використання може стати бар’єром у розумінні проєкту. Навіть якщо Docker в проєкті не використовується, то скоріше за все він з’явиться там дуже скоро. З Docker різниця між нуль і трошки дуже велика. Тому залишати цей скіл на нулі не варто.

Що стосується самого тестування програмного забезпечення (ПЗ), то це велика зона для професійного росту. Навички тестування дають змогу розвивати багато суміжних зон, наприклад, автоматизація, дизайн-патерни, скіл рефакторингу та інше.

Також навички тестування відкривають доступ до continuous improvement системи. Без тестів будь-яка спроба щось покращити скоріше за все обернеться регрешином та додатковими проблеми. Крім того, зменшується human factor. Можна захиститись і від своїх помилок, і від чужих — можна буде валідувати ченджі інших та швидко знаходити проблеми.

Що варто знати для тестування з Docker?

Для тестування треба не так багато знань Docker. Потрібно вміти збілдити простий Docker image. Варто знати, що є ключове слово from — щоб вказати, який image ми хочемо взяти за основу і використовувати. По дефолту це Docker Hub.

Основні команди

• FROM nginx
• COPY default .conf / etc/nginx/conf .d/default . conf
• COPY build / usr / share/nginx/html
• COPY ./nginx_launch . sh
• CMD / bin/bash ./nginx_launch . sh

З CMD варто пам’ятати, що процес тут повинен бути не бекграунд. У тому самому nginx він запускається як бекграунд процес — ми запустили команду й одразу управління повернулось в термінал. Нам треба запускати nginx з флагом Foreground, щоб управління не поверталось в термінал.

І ще потрібно знати, що Docker ps видає лістинг всіх запущених імеджів в системі, і що існує docker exec -it {hash} контейнера, який можна взяти з docker ps, і команда, яка має виконатись всередині. Це може нам знадобитись для дебагінга.

Проте набагато зручніше і простіше використовувати Docker Compose, ніж Docker напряму.

Docker Compose

Краще використовувати Docker Compose, в порівнянні з ручним написанням та запуском довгих docker команд. Плюс з Docker Compose все сториться в файлі, та можна задавати запуск декількох контейнерів.

З цікавого в Docker Compose можна виділити:

• прокидування портів: по дефолту ми не матимемо доступу до контейнерів через локал хост
• можна задавати environment variables
• можна підключати volums — це mount директорії.

В Docker Compose буде достатньо наступних команд:

• docker -compose up
• docker -compose stop, щоб зупинити контейнер, не видаляючи його стан
• docker -compose down, щоб зупинити та видалити всі існуючі стейти, які прив’язані до контейнера, за винятком mounted directories.

Використання Docker в тестах

Використання third-party програм в сервісах

З усією темою мікросервісів, а особливо з AWS, використовується багато стороннього софту в програмах. Відповідно, щоб правильно тестувати інтеграцію, нам бажано взаємодіяти з реальним бінарником, а не просто мокати все. Особливо, коли у нас є база даних і якась логіка в SQL. Через моки JVC темплейта, асерти sql-запитів ніякого тестування не виконується. Фактично ми просто каплимо тести до імплементації, і вони падають частіше, і на їх підтримку буде йти багато часу.

Тестування в інтеграції з іншими мікросервісами

Суть залишається та ж сама, але бажано мати pipelines для CI, які будуть білдити Docker контейнери. Так ми зможемо тестувати інтеграцію з реальними сервісами замість того, щоб мокати http-запити, change-реквести і т.д.

Написання е2е тестів для системи

Коли інфраструктура стає дуже розгалуженою і стає дуже багато різних сервісів, девелопиться зазвичай один сервіс, а працювати має все разом. Відповідно без великої кількості інтеграційних тестів відловити регрешни стає дуже складно. Docker допомагає в цьому, ми зможемо підіймати власні environements з набору Docker images (власних і third-party) і запускати тести для них.

Переваги тестування в Docker

Тести ізольовані один від одного

Раніше, коли ми намагались тестувати скажімо базу даних, нам потрібно було щось накачувати, щось відкачувати, управляти купою всього замість того, щоб писати реальні тести та запускати їх. З допомогою Docker ми дуже швидко видаляємо і запускаємо пустий state, в якому і ранимо тести.

Можливість паралельного запуску тестів

Через створення декількох контейнерів в Docker ми можемо запускати тести паралельно. При цьому менше потрібно слідкувати за state, в тому числі за алокацією портів і т.д. Це можна робити автоматично, і з нашого клієнтського коду в тестах не буде нічого видно про ініціалізацію, очищення тощо.

Не потрібно встановлювати софт на тестове середовище

Наприклад, в середині нашої програми ми використовуємо якийсь third-party бінарник, який конвертує html в pdf. Цей бінарник не має бібліотеки, яка інтегрується в нашу мову програмування. Ми просто запускаємо його як команду, і нам потрібно відповідно на кожну робочу станцію встановлювати цей бінарник, витрачаючи час на онбординг робочої машини, на фікси пов’язані з неправильною версією, баги пов’язані з версією під конкретну операційну систему і т.д.

Або ж ми можемо написати тести, в яких буде використовуватись Docker image, і запускати бінарник з нього. Таким чином ми отримуємо той самий функціонал без ряду проблем. З нашого онбордингу залишається лише інсталяція Docker в систему.

Можливість керування залежностями в проєкті (infrastructure as a code)

Через те, що структура проєктів стає всі більшою і більшою, все це треба зводити до одного цілого. З допомогою Docker можна всі ці залежності прописати в текстовому вигляді та швидко і зручно все запускати. Проте в таких ситуаціях все-таки краще використовувати Kubernetes, оскільки у ньому більш гнучка система управління, особливо refferences.

Можливість використовувати заготовлені data set з допомогою власних Docker images

Уявимо наступну ситуацію. У нас вже є багато legacy коду, і нам для тестування треба мати заготовлені структури, бо створити їх вручну через якесь АРІ складно. В такому випадку ми можемо використовувати не просто image Postgres, а image Postgres прямо з бекапом даних і запускати заготовлені тести та управляти дата сетами окремо від самих тестів.

Існуючі фреймворки для Java, які використовував наш колега:

• Localstack (AWS) GitHub.com/localstack/localstack, що є імплементацією AWS сервісів.
• Testcontainers (testcontainers.org), який надає Java АРІ для наших тестів, щоб контейнери використовувати як Java АРІ.

Декілька порад

“Не знаю Docker і не пишу тести”

• Експериментуй з е2е тестами в semi-automatic режимі
• Користуйся docker-compose для підйому залежностей системи
• Можливо, поекспериментуй з Selenium

“Знаю Docker і не пишу тести”

• Експериментуй з е2е тестами
• Пробуй використовувати стаби на images
• Інтегруй flyway в проєкт

“Пишу mock-тести”

• Пробуй заміняти моки на справжні реалізації з допомогою Docker
• Паралель тести

“Знаю Docker і пишу тести

• Піднімай code coverage — 100%
• Покращуй розуміння і прозорість code coverage
• Паралель запуск
• Рань тести на remote