Автотесты на GitHub

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

Количество попыток ограничено, так как серверное время не бесконечно. Поэтому на запуск каждой работы у Вас в среднем не более 30 попыток (для каждой работы это значение может варьироваться и будет указано в условии работы).

Почему важно запускать автотесты:

1. Если вы совершили какую-нибудь глупую ошибку и отправили код на проверку, то получить ответ вида "результаты работы оформлены не по шаблону" или "не всё отправлено на проверку" вы можете спустя 3-4 дня, хотя правка такой ошибки занимает от силы пару минут.

2. Также в случае, если у вас есть возможность запускаться только на одной системе, например, Linux, то найти ряд ошибок, которые сходу видно под Windows вы сможете либо в ответе проверяющего (что опять же долго ждать), либо сразу увидите это в логах.

В репозиториях курса можно запускать как все тесты сразу, так и отдельные тесты.

Как же вас собирают на сервере?

Сборка C/C++

1. Файл, содержащий функцию main должен называться main.c или main.cpp и лежать в корне репозитория. В случае обнаружение первого всё решение собирается как код на C, иначе – C++.

2. Затем рекурсивно находятся все *.c и *.cpp файлы в репозитории и подаются на компиляцию.

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

   2. Используемые ключи компиляции [-std=c23 || -std=c++23] -O2 -Werror=return-type -Werror=strict-prototypes -Wvla -Wunused-variable -lm.

Разные компиляторы могут в одних стандартных заголовочных файлах автоматически подключать другие (по стандарту они не обязаны этого делать). И самая частая ошибка, из-за которой не собирается под Windows, но собирается под Ubuntu – не подключены нужные заголовочные файлы.

Запуск всех тестов через GitHub Actions

Чтобы была возможность на ранних этапах выполнения работы проверить работоспособность программы на автотестах на Github на части тестов, была добавлена опция для запуска автотестов с параметрами.

1. Отправить в репозиторий файлы с исходным кодом.

2. Перейти в раздел Actions. Там выбрать workflow (BuildTest или CI/CD), после чего в меню запуска Run workflow проставить галочки у тестов которые вы хотите запустить (галочки для преподавателей/проверяющих проставлять не надо). У галочек добавлено описание, что они означают.

   
3. Дождаться окончания запуска. Новый запуск (run) появляется в списке запусков с некоторой задержкой (до 10 секунд), так что наберитесь терпения или press F5.

4. Ознакомиться с результатами запуска. Если всё прошло успешно, то в Summary запуска вы увидите что-то в таком духе (скрин ниже):

   1. 1 – запуски (job) на 1 или 2 ОС

   2. 2 – Summary по каждому запуску (job). Это отчет, который оформлен для вас в человекочитаемом виде, чтобы вы не страдали и не разбирались в логах.

   В Summary отображается статус проверки и ниже приводятся логи тестов на обеих системах. Логи условно разделены на 3 части: Install dependencies / Init / Detect language, Build, Test. Build содержит информацию о компиляции и линковке.

   

Куда надо смотреть, чтобы ознакомиться с результатами и ошибками? В Summary запуска:

Если вы видите, кто run не завершился успешно, то всё ещё смотрим в Summary:

Куда НЕ надо смотреть – в логи с сервера:

Ход тестирования (консольный интерфейс)

Запускать автотесты можно как через web-интерфейс, так и с использванием gh API (имя .yaml файла можно найти в репозитории в .github/workflow):

gh workflow run ci.yaml --ref main -f <field>=<value>

Название полей и значений будет приведено в условии каждой работы.

gh workflow run ci.yaml --ref main -f grey_test=false -f rgb_test=true

Проверка статуса: gh run list --workflow=ci.yaml

Просмотр прогресса: gh run watch -i 1

Подробнее: https://cli.github.com/manual/gh_run

Ход тестирования (web-интерфейс)

Логи проверки можно посмотреть в разделе Actions для последнего запуска (самый верхний).

GitHub Actions - Failed with Logs

---

В разделе Inputs отображаются следующие сведения:

1. параметры, введённые при запуске. При их отсутствии выводится null;

2. ссылка на текущий репозиторий;

3. коммит репозитория студента, на котором проводился запуск тестов;

4. коммит репозитория с тестами, на котором проводился запуск тестов.

GitHub Actions - Inputs

---

Этап Detect language будет в работах, где необходимо писать код на одном из допустимых языков программирования. Если всё хорошо, то будет показан язык и версия инструментария на сервере Github.

GitHub Actions - Detect language

Иначе будет выдано следующее. В таком случае нужно проверить, что все исходники лежат в репозитории и требования по их отправке выполнены.

---

Следующий шаг - Build. Если логи сборки пустые, то в Summary этого шага видно не будет. Иначе вуду выведены логи компилятора и линковщика. Например:

GitHub Actions Failed with Logs

---

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

Если все тесты пройдены верно, то вы увидите следующее

GitHub Actions Testing (v1)

(другой вариант оформления)

GitHub Actions Testing (v2)

Здесь указывается путь с гиперссылкой на входной, выходной файлы, код возврата, полученный от вашей программы, логи потоков вывода и вывода ошибок, а также общий статус (PASSED, FAILED). Последняя строка отладочная для проверяющего.

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

GitHub Actions Testing Failed(v1)

(другой вариант оформления)

GitHub Actions Testing Failed(v2)

По результатам тестов вам в репозиторий с GitHub серверов будут залиты выходные файлы. Все тестовые файлы лежат в репозитории в директории test_data.

Если тесты на Ubuntu не отработали полностью корректно, то на Windows проверка не будет запущена. Поэтому если вы видите, что проверка завершилась неуспешно и вы не понимаете почему, то вместо того, чтобы тратить попытки на GitHub (которые у вас ограничены), лучше сразу написать проверяющему о своей проблеме.