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

Question

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

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

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

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

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

Answer 1

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

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

Вот пример Dockerfile я использую для инкапсулирования 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's needed but not for the build 
COPY supportfiles /usr/src/testng/supportfiles 

CMD [ "mvn test" ] 

Answer 2

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

процитирую Alister Scott из GTAC 2015 которой я присутствовал:

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

Для интеграции и испытаний e2e, т.е.тесты, для которых требуется более одного изображения докеров, я предпочитаю CI tool, который через docker-compose и отдельное репозитование git для этих тестов организует создание всех контейнеров, необходимых для более крупного теста. Опять же, изображения докеров использовались should be the exact same as for production, за исключением what varies is the configuration (например, переменные среды), которые заставляют тесты указывать на тестовые данные и/или промежуточные службы.