Для чего юзают Docker, с какой целью его применять для автотестинга ?

Понятно. Спасибо.

И каким макаром это делается ?
Прост делал обычный Hello World в докере.
Можете примерно расписать шаги, как создается docker image, чтобы я его мог передать коллеге ?
На примере простого проекта.
И что должно быть установлено у коллеги ?

Насколько я понимаю (на примере java-тестов):
Берётся докер с java, нужным браузером (есть официальные докеры).
К нему добавляется мавен или грэдл для сборки проекта.
Добавляется код тестов.
Добавляется команда на сборку и запуск этих тестов.
Докер сохраняется в своём или открытом хранилище докеров.
Разработчик запускает нужный докер 1 командой, указывая откуда брать докер (из своего или открытого хранилища).

Т.е. исходя из примера - раз настроив такую сборку докера - вы гарантированно получаете запуск тестов в нужном браузере не важно где - у себя на машине, на машине разраба, или на каком-то сервере (т.к. они запускаются в докере).

1 лайк

Понимаю.

Берётся докер с java, нужным браузером (есть официальные докеры).

ok, допустим нашел такой официальный образ

К нему добавляется мавен или грэдл для сборки проекта.

А как добавить мавен в этот же образ ?

Добавляется код тестов.

Как добавляется код тестов ?

Хотя бы примерные команды ?

А какое преимущество поднятого Jenkins в докере или просто Jenkins на сервере? Здесь тоже любой человек, может зайти в Jenkins и запускать тесты.

Могу только посоветовать начинать с этого:

Основные команды в этом разделе - Dockerfile instructions.

Вот пример ещё (Start a Java instance in your app):
https://hub.docker.com/_/openjdk

1 лайк

Не знаю, никогда не запускал Дженкинс в докере.
Возможно, что у вас уже есть готовая инфраструктура для докеров и вам надо развернуть быстро Дженкинс - тогда да, одной командой это всё разворачивается.

Посмотрите фреймворк TestContainers. Вы один раз его попробуете и больше никогда не захотите использовать DB или Kafka (или любой другой внешний сервис) для интеграционных тестов вне контейнера. Там есть и Браузер с вебдрайвером, если к примеру нужно это запустить на CI-Агенте, где кроме Docker ничего нет.

Смысл в том, чтобы загрузить и поднять любой внешний для вашего приложения сервис или группу сервисов на время тестов, а потом безопасно убить. И каждый запуск получается stateless на свежем окружении. Также можно поднять несколько инстансов окружения и распараллелить тесты на уровне окружений без синхронизации в коде или каких либо коллизий между потоками (но это уже Kubernetes нужен).

И тут встает вопрос ресурсов Памяти и Процессора на машинах с Docker (или Kubernetes), то есть масштабирование ничем не ограничено кроме ресурсов.

1 лайк

Ок, допустим такую ситуацию.
У меня написаны и бегают UI тесты с использование Java 8 + maven + TestNG + Selenide.

Я так понимаю, что теперь нужно написать Dockerfile.

Как мне узнать какой FROM вызывать первой строчкой в файле ?
FROM java
или
FROM maven ?

И еще такой вопрос:

  1. могу ли я в свой image включить уже созданные images другими людьми ? Если да, покажите пожалуйста примеры.
  2. Верно понимаю, что эти контейнеры понимает только докер. То есть не имея докера этот контейнер никак не запустить другими способами ?

Нет. Вам нужно базовую теорию сначала изучить. Начать можно:

  • установить Docker для Linux или Windows (на свою тачку)
  • выполнить docker run -d -p 80:80 docker/getting-started
  • скачается image веб приложения getting-started и будет доступен на http://localhost
  • там много полезной информации для начала

Так вот в вашем случае вами тесты нет необходимости разворачивать в контейнере и писать Dockerfile не нужно.

Допустим вы хотите протестировать приложение docker/getting-started и у вас машина без chromedriver и браузера Chrome и вообще без интерфейса, но установлен Docker и docker-compose.

В файле docker-compose.yml описывается стенд приложение + браузер
version: "3.7"
services:
  browser:
    image: selenium/standalone-chrome:85.0
    ports:
      - 4444:4444

  testing-application:
    image: docker/getting-started
    ports:
      - 80:80
Запускаете этот файл docker-compose -f docker-compose.yml up -d
Вы можете зайти в приложение по http://localhost:80/, а к браузеру можете подключиться через RemoteWebDriver по http://localhost:4444/wd/hub
Между контейнерами в сети docker-compose DNS имена используются сервисов, то есть чтобы из контейнера браузера попасть на docker/getting-started нужно вводить в браузере http://testing-application:80

Пример, правда на котлин github.com/kochetkov-ma/pump-samples/tree/master/docker-sample
Достаточно просто запустить gradle docker-sample:test и если у вас установлен Docker + Docker-Compose и есть доступ до Docker Hub, то TestContainer все сам скачает и запустит docker-compose.yml, а потом убьет

1 лайк

Это уже пройдено. С теорией знаком.

Хотелось бы услышать ответы на мои вопросы.

PS: > Так вот в вашем случае вами тесты нет необходимости разворачивать в контейнере и писать Dockerfile не нужно.
RLY ? Это почему это ?

FROM maven:3.6.3-jdk-8 - Docker ( Supported tags and respective Dockerfile links )

Либо, вы можете посмотреть как этот докер получается - docker-maven/Dockerfile at 26ba49149787c85b9c51222b47c00879b2a0afde · carlossg/docker-maven · GitHub
Смодифицировать его и добавить ещё свои команды на копирование исходников тестов и запуск их.
Докер композ - как раз пример того как несколько докеров связывать, в каждом запускается какое-то приложение и они общаются (как Максим подсказал). Например - в одном докере компилятся и выполняются тесты, в другом - запускается само приложение, в третьем запускается браузер и в нём выполняются тесты. Можно это упростить до 1 докера в который вы сами копируете к тестам еще и сам браузер и у вас всё в одном.

1 лайк

Dockerfile - это описание того, как собрать приложение, поместить его в какую то среду и запустить, чтобы оно работало в режиме сервера как правило.
Далее собранный образ публикуется в Registry и доступен для публичного использования.

Тесты не являются приложением которое работает в режиме сервера и собирать их в образ не имеет никакого смысла, хотя кто-то так делает для Kubernetes, но я считаю это ошибкой.
Тесты запускаются на ХОСТ машине, а тестируемое приложение разворачивается в контейнерах.
Если варианты с CI агентами в контейнерах, но я не буду углубляться в эту тему.

Ответы на ваши вопросы:

  • Да. Это называется базовый образ и указывается в самом начале Dockerfile FROM alpine - базовый образ Linux Alpine. Можно указать абсолютно любой.
  • Нет. Контейнеры может поднимать не только Docker. Сейчас реализаций уже довольно много, в том числе нативная встроенная в Linux, а также Podman и они понимают Dockerfile для сборки образа.
    Но пока стоит ориентироваться только на Docker
1 лайк

Верно - тесты, это не само приложение и нет смысла их заворачивать в image.
Тогда возвращаясь к первому посту: с какой целью его(докер) применять для автотестинга ?
Никак не могу уловить.

  • разработчики разработали приложение
  • положили код в репозиторий
  • затем собрали образ приложения в контейнер и положили в хранилище артефактов
  • вы где угодно скачиваете образ контейнера и сколько угодно копий запустили
1 лайк

Удобно в случае, если вам нужно запускать тесты параллельно, с использованием разных браузеров и OS, с разными переменными окружения, например, или версиями какой-нибудь синтегренной к приложению внешней библиотеки. В контейнере работает для этих целей тот же Selenium Grid.
Jenkins можно соответственно разворачивать там же, в контейнере. Но можно и не делать так.

Тесты можно не заворачивать в имейдж, но ранать их внутри него.
Пример - CI построенный на TeamCity, где на куче агентов ранаются джобы, в том числе и тесты.
Доступа к настройке окружения на агенте у тебя нет - можно либо оформлять кучу заявок на установку нужного тебе ПО, потом терзать инженеров, чтобы они донастроили то что тебе нужно, либо создать доккер имейдж настроенный как тебе надо, и ранать свои тесты внутри этого контейнера. Сам код тестов при этом каждый запуск пуллится непосредственно внутри контейнера, т.е хранится все по отдельности - код в своем репозитории, доккер в своем

В каждой CI есть возможность настроить агенты-контейнеры.
Они поднимаются в контейнере с git и другими приложениями пробрасывают сокет докера с хост машины, либо сами с докером внутри. А внутри контейнера уже разворачиваются еще контейнеры стенда - называется DockerInDocker (DinD).

Подкажите, с Selenide удобно использовать TestContainers?

С TestContainers удобно использовать как Selenide так и Selenium. Просо нужно из контейнера получить ссылку на remote web driver и записать в конфиг Селенида, например так Configuration.remote = "http://" + browser.host + ":" + browser.firstMappedPort и все. Далее все будет происходить внутри контейенера.

А образ можно использовать например такой new BrowserWebDriverContainer<>(DockerImageName.parse("selenium/standalone-chrome:4.1.0")) - он будет сразу с Хромом внутри и хромд-райвером под 4-ый селениум. Пример для Kotlin: selenide-pages/TestConfiguration.kt at main · kochetkov-ma/selenide-pages · GitHub

1 лайк