На хорошем производстве существует входной и выходной контроль. Наверное, многие видели на технически сложных изделиях отметки ОТК, PASSED, QUALITY CHECK PASSED.
Приложение, упакованное в контейнер, тоже является технически сложным изделием. До развёртывания в боевой среде стоит смоделировать его поведение и протестировать.
Протестировать можно несколькими вариантами: * отдать заказчику; * проверить самому; * написать карточку тестирования; * написать автоматический тест.
Рассмотрим задачу публикации предварительно подготовленной промо-страницы в сети Интернет. Стандартная промо-страница состоит из картинок и текста с относительно неплохим дизайном. Что на этой странице можно проверять? * код ответа веб-сервера; * заголовки ответа веб-сервера; * текст на наличие ошибок; * оформление; * анимацию; * и т.д.
Каждый ручной тест отнимает самый дорогой наш ресурс - время. Допустим, вы реализовали задачу по размещению внутри контейнера этой страницы. Как другим участникам процесса убедиться в том, что вы сделали то, что было нужно?
Можно сделать это вручную. А именно - содержать в электронной таблице, в базе знаний, документах список сценариев и каждый раз их проходить. Вручную.
Сомневаюсь, что найдутся 100% прилежные люди, которые в состоянии полностью пройти все сценарии (если сценариев больше 100).
На большом проекте количество вариантов сценариев измеряется десятками (или даже сотнями) тысяч. Чтобы проводить релизы несколько раз в день, нам нужны сотни прилежных людей. Понятно, что такого количества людей мы не найдём.
На этом шаге команды делятся на 2 типа:
1) тестируют малую часть функционала “вручную”; 2) заменяют ручное тестирование автоматическим.
Тестирование вручную
Например, в программе 10 вариантов развития событий. Можно ли пройти их вручную? Наверное, да. При этом:
1) кейсы должны быть описаны в понятном для сотрудника формате; 2) сотрудник должен понимать, где кейсы хранятся, как их пополнять и удалять ненужные 3) сотрудник должен понимать, как проходить по кейсам (как создать площадку, подобную “боевой”, откуда брать данные для тестирования и т.д.)
Запуск автоматических тестов локально
Запускаем selenium
docker run -d --shm-size=2g --network bridge --name selenium-chrome selenium/standalone-chrome
Узнаём IP адрес созданного контейнера с selenium
docker inspect selenium-chrome
Экспортируем переменные окружения
export SELENIUM_CHROME_ADDRESS=IP адрес контейнера с selenium
export FQDN=адрес веб-сервера
Ставим зависимости
composer install
#если падает с ошибкой отсутствия какой-либо зависимости, можно вызвать с ключиком --ignore-platform-reqs
composer install --ignore-platform-reqs
Запускаем тесты
./vendor/bin/codecept run