Запуск тестов, как обычно, против докерных контейнеров или докеризационных тестов?

Я новичок в Docker и читаю на Docker. Это отличный способ тестирования систем в автономной и воспроизводимой стандартизованной конфигурации (когда все сделано правильно).

Однако во всех вещах, которые я прочитал, похоже, слишком много внимания уделяется тому, как тестирование должно происходить с контейнерами докеров. Докер используется, чтобы "содержать" инфраструктуру и приложение (код) для легкого тестирования (а также развертывания). Но иногда тестовые кодовые базы являются большими и не слишком простыми. И можно иметь тестовую кодовую базу для тестов API, другую для пользовательского интерфейса и т.д.

Что такое или должно быть (как определено в какой-то момент) стандартная практика тестирования контейнеров-докеров/развертывания ваших приложений/инфраструктуры? В случае, если:

тестовый код должен быть развернут старым обычным способом, как репозиторий файлов, который вы вытаскиваете откуда-то, а затем запускаете на сервере/подчиненном сервере Jenkins или один локальный хост для тестирования/отладки dev/QA, с тестами, ориентированными на приложения в контейнере докеров?
присоединяет всю базу тестового кода как автономный контейнер и затем использует этот контейнер для запуска/выполнения тестов с другими контейнерами, у которых есть инфраструктура приложения/системы.
объединить тесты как часть отдельных контейнеров докеров, которые будут запускаться при необходимости. Но я думаю, что это лучше всего работает только для модульных тестов, которые действительно сочетаются с контейнером, который содержит соответствующий код приложения. Интеграция, пользовательский интерфейс, тесты уровня системы различаются в зависимости от модулей приложения внутри системы.

Единственная причина, по которой я могу думать о том, что, возможно, полезны тесты для докетирования, - это один контейнер со всеми необходимыми вами тестами и соответствующей тестовой инфраструктурой (все зависимости тестовой платформы/языка), чтобы можно было развернуть и запустить тесты в любом месте вместе с соответствующими контейнерами кода приложения. Сохраняет одно из того, что нужно настроить тестовую инфраструктуру по мере необходимости. Но, похоже, не было сообщений о таких вещах для докционированных тестов.

Ответ 1

Я предпочитаю ваш вариант (3), то есть включить тестовый код в производственный разворачиваемый артефакт (изображение докера)

Процитирует Алистер Скотт из GTAC 2015, который я присутствовали:

Не бойтесь добавлять специальные возможности к тестированию в ваше приложение, которые не служат функциональной цели. Недавно мне пришлось покупать новые шины на своей машине и поняли, что у многих шин есть возможности тестирования, называемые индикаторами протектора. Они не служат функциональному назначению

Для тестов интеграции и e2e, то есть тестов, для которых требуется более одного изображения докеров, я предпочитаю инструмент CI, который через docker-compose и отдельный репо для git для этих тестов, организует создание всех контейнеров, необходимых для более крупного теста. Опять же, изображения докеров, используемые должны быть такими же, как для производства, кроме что меняется это конфигурация (например, переменные среды), которые заставляют тесты указывать на тестовые данные и/или сервисные службы.

Ответ 2

Я не думаю, что вы сами доквалифицируете тесты как процесс, который запускает тесты.

Например, если вам нужно запустить модульные тесты в php с phpunit, вы должны dockerize phpunit и использовать это для запуска тестов против ваших код и аналогично для любой другой используемой тестовой среды (например, testng, junit... и т.д.)

Вот пример файла Docker, который я использую для инкапсуляции Java/Maven/TestNG для тестового Java-проекта, который включает в себя некоторые тесты селена:

FROM maven:3-jdk-8

# Selectively add stuff we need
COPY pom.xml /usr/src/testng/

# Get a clean build immediately after and 'go-offline' to improve subsequent builds
RUN cd /usr/src/testng && mvn dependency:go-offline
COPY src /usr/src/testng/src
WORKDIR /usr/src/testng/

# Additional support files that needed but not for the build
COPY supportfiles /usr/src/testng/supportfiles

CMD [ "mvn test" ]