go-autotests

Автотесты для курса "Go-разработчик".

Локальный запуск

Трек "Go и DevOps"

Скомпилируйте ваши сервер и агент в папках cmd/server и cmd/agent командами go build -o server *.go и go build -o agent *.go соответственно
Скачайте бинарный файл с автотестами для вашей платформы (например devopstest-darwin-arm64 - для MacOS на процессоре Apple Silicon)
Разместите бинарный файл так, чтобы он был доступен для запуска из командной строки (пропишите путь в переменную $PATH)
Ознакомьтесь с параметрами запуска автотестов в файле .github/workflows/devopstest.yml вашего репозитория, автотесты для разных инкрементов требуют различных аргументов для запуска

Пример запуска теста первого инкремента:

devopstest -test.v -test.run=^TestIteration1$ -agent-binary-path=cmd/agent/agent

Трек "Веб-разработка на Go"

Скомпилируйте ваш сервер в папке cmd/shortener командой go build -o shortener *.go
Скачайте бинарный файл с автотестами для вашей платформы (например shortenertest-darwin-arm64 - для MacOS на процессоре Apple Silicon)
Разместите бинарный файл так, чтобы он был доступен для запуска из командной строки (пропишите путь в переменную $PATH)
Ознакомьтесь с параметрами запуска автотестов в файле .github/workflows/shortenertest.yml вашего репозитория, автотесты для разных инкрементов требуют различных аргументов для запуска

Пример запуска теста первого инкремента:

shortenertest -test.v -test.run=^TestIteration1$ -binary-path=cmd/shortener/shortener

Автоматический запуск

Авто-тесты

Для проверки того, насколько код инкремента удовлетворяет функциональным требованиям задания, мы используем авто-тесты. Они запускаются внутри CI/CD-инструмента Github'а под названием Github Actions.

Github Actions (далее - GA) позволяет с помощью собственного синтаксиса описывать некоторый набор операций (workflow), которые должны применятся к коду автоматически при изменениях (или по нажатию кнопки). На практике, с помощью CI/CD часто автоматизируют синтаксические анализаторы, автотесты, генерацию документации, выкатку на различные окружения и так далее. При этом все эти действия выполняются не в вакууме: в нашем случае, Github предоставляет свои машины (называмые runner'ами), где наш код и будет выполнятся в соответствии с заготовленными конфигурациями.

Если вкраце, GA разбивает каждый workflow на несколько job (которые могут работать последовательно или параллельно), они в свою очередь состоят из одного или нескольких steps, в которых мы можем указывать конкретные действия, которые должны быть выполнены. Также вы можете указать условия выполнения workflow (например, можно настроить выполняться на каждый коммит в ветке main), что позволяет гибко настраивать все ваши самые извращенные CI/CD-фантазии.

ПРИМЕР WORKFLOW-КОНФИГА, КОТОРЫЙ МЫ ИСПОЛЬЗУЕМ ДЛЯ АВТОМАТИЧЕСКОГО ПРИМЕНЕНИЯ go vet

name: go vet test # название workflow

# если мы хотим настроить автоматическое применение workflow в зависимости от условий
# то мы используем ключевое слово 'on'
on: 
  pull_request: # здесь говорим, что запускаем workflow для любого события внутри PR (пуш, тэг и тд)
  push:
    branches: # здесь мы говорим, что хотим применять workflow и для пушей в main-ветку
      - main

# каждый workflow представляет из себя набор из джоб
# которые выполняются последовательно или параллельно
# для каждой джобы можно задать докер-образ, в котором будут выполняться шаги (steps)
# и ОС, в которой будет запущен контейнер
jobs:
  statictest: # описываем джобу statictest
    runs-on: ubuntu-latest # говорим, что джоба должна выполняться на машине с убунтой (предоставляется гитхабом)
    container: golang:1.18 # запускаем в ней контейнер докер-образа golang:1.18
    steps: # последовательно выполняемые шаги
      - name: Checkout code
        # Github Actions позволяет как самому описывать команды линукса внутри шага
        # так и использовать заготовленные шаги, как здесь
        uses: actions/checkout@v2 


      - name: Download statictest binary
        # или здесь
        uses: robinraju/release-downloader@v1
        with:
        # для заготовленных шагов иногда требуется указать параметры, как здесь
          repository: Yandex-Practicum/go-autotests
          latest: true
          fileName: statictest
          out-file-path: .tools

      - name: Setup autotest binary
        # тут мы уже описываем произвольный набор команд
        run: |
          chmod -R +x $GITHUB_WORKSPACE/.tools/statictest
          mv $GITHUB_WORKSPACE/.tools/statictest /usr/local/bin/statictest

      - name: Run statictest
        run: |
          go vet -vettool=$(which statictest) ./...

Работает это следующим образом:

Когда вы подтягиваете шаблон проекта, вместе с ним у вас также подтягивается директория .github/workflows. В ней находится два workflow-файла: statictest.yaml и shortenertest.yaml/devopstest.yaml (в зависимости от того, какой шаблон вы стянули)
В следующий раз, когда вы выполните изменения в репозитории (например, запушите коммит), которые попадают под условия описанные в on workflow-конфигов в папке .github, Github Actions выполнит все джобы в каждом файле (по умолчанию - параллельно)
В интерфейсе PR'а, вы можете увидеть ход выполнения джоб, либо можно перейти во вкладку Actions
Слева во вкладке Actions есть список workflow, например, если мы хотим посмотреть ход выполнения автотестов, мы переходим в autotests
Перейдя в интересующий нас workflow, мы видим страницу с историей выполнения только этого workflow. Чаще всего нас интересует последний так как он, вероятно, был выполнен на самой актуальной версии кода. Кстати, не удивляйтесь тому, что у вас воркфлоу помечен красненькой иконкой - она сменится на приятную глазу зеленую только когда вы выполните все инкременты курса.
Провалившись в последний выполненный autotests воркфлоу мы видим несколько джоб:
Разберем провалившийся тест одного из инкрементов
После того, как у вас завалится какой-то из шагов джобы, джоба завершится, а все контейнеры и их содержимое удалятся.