Автотесты на GitHub
В ваших репозиториях настроены автотесты для проверки, что код в состоянии собраться и собранный исполняемый файл отрабатывает верно.
Количество попыток ограничено, так как серверное время не бесконечно. Поэтому на запуск каждой лабораторной работы не более 7-10 попыток (для каждой работы будет прописано в условии), для домашней – не более 5 попыток.
Мотивация
Если вы совершили какую-нибудь глупую ошибку и отправили код на проверку, то получить ответ вида "ответ выведен не в том формате" вы можете спустя 3 дня, хотя правка такой ошибки занимает от силы пару минут.
Также в случае, если у вас есть возможность запускаться только на одной системе, например, Linux, то найти ряд ошибок, которые сходу видно под Windows вы сможете либо в ответе проверяющего (что опять же долго ждать), либо сразу увидите это в логах.
Чтобы не использовать впустую попытки, вы можете запускать тесты локально (инструкция в README.md в репозитории).
Запуск автотестов
В репозиториях курса можно запускать как все тесты сразу (как было сделано в тестовом репозитории), так и отдельные тесты.
Чтобы была возможность на ранних этапах выполнения работы проверить работоспособность программы на автотестах на Github на части тестов, была добавлена опция для запуска автотестов с параметрами.
Для этого нужно:
Отправить в репозиторий файлы с исходным кодом.
Перейти в раздел Actions. Там выбрать workflow BuildTest, после чего в меню запуска Run workflow проставить галочки у тестов которые вы хотитте запустить. У галочек добавлено описание, что они означают.
Дождаться окончания запуска. Новый запуск (run) появляется в списке запусков с некоторой задержкой (до 10 секунд), так что наберитесь терпения или press F5.
Ознакомиться с результатами запуска. Если всё прошло успешно, то в Summary запуска вы увидите что-то в таком духе (скрин ниже):
1 – запуски (job) на двух разных ОС
2 – полученные с сервера выходные файлы. Если запуск завершился неуспешно или выходные файлы не созданы, то данного “артефакта” может не быть.
3 – Summary по каждому запуску (job). Это отчет, который оформлен для вас в человекочитаемом виде, чтобы вы не мучались и не разбирались в логах.
Запускать автотесты можно как через web-интерфейс, так и с использванием gh API
Название полей и значений будет приведено в условии каждой работы.
Здесь говорится о том, что проверка будет только на цветной картинке.
Ход тестирования (консольный интерфейс)
Проверка статуса: gh run list --workflow=Buildtest.yaml
Просмотр прогресса: gh run watch -i 1
Подробнее: https://cli.github.com/manual/gh_run
Ход тестирования (web-интерфейс)
Когда начнётся тестирование на одном из серверов, то будет отображаться
Если же что-то пошло не так, то будет отображаться следующее:
Детально логи проверки можно посмотреть в разделе Actions для последнего запуска (самый верхний).
Если в Install dependencies / Init не выводится Done, то что-то совсем пошло не так и нужно написать преподавателям.
Этап Detect language будет в работах, где необходимо писать код на одном из допустимых языков программирования. Если всё хорошо, то будет показан язык и версия инструментария на сервере Github.
Следующий шаг - Build.
При компиляции по всему репозиторию находятся файла с расширениями *.c и *.cpp.
В качестве include directory берётся корень репозитория, директория include и дополнительные директории, необходимые для автотестов.
Компиляция происходит из командной строки, поэтому никакие Makefile, CMakeLists.txt и прочие файлы для соответствующих систем сборки не учитываются. Если очень хочется разделить заголовочные от файлов с исходным кодом, то размещаем заголовочные в include (её нужно создать самостоятельно).
Если логи сборки пустые, то в Summary этого шага видно не будет. Иначе будут выведены логи компилятора и линковщика. Например:
Если же ваш код собрался, то начинается выполнение шага Test, в котором ваша программа проверяется на каком-то простеньком для каждого задания тесте (или нескольких тестах).
Если все тесты пройдены верно, то вы увидите следующее
Здесь указывается путь с гиперссылкой на входной, выходной файлы, код возврата, полученный от вашей программы, логи потоков вывода и вывода ошибок, а также общий статус (PASSED, FAILED). Последняя строка отладочная для проверяющего.
Если же ваша программа не выполняет все функциональные требования согласно заданию и требованиям к работам, то тесты не пройдут и вы увидите сообщение об ошибке. Например, ниже представлен случай, когда программа завершилась с ненулевым кодом возврата и вывела сообщение об ошибке.
По результатам тестов вам в репозиторий с GitHub серверов будут залиты выходные файлы. Все тестовые файлы лежат в репозитории в директории test_data. Здесь указывается путь с гиперссылкой на входной, выходной файлы, код возврата, полученный от вашей программы, логи потоков вывода и вывода ошибок, а также общий статус (PASSED, FAILED). Последняя строка отладочная для проверяющего.
Проверка на оформление кода clang-format является неблокирующей, поэтому удостовериться, что вы всё правильно отформатировали, должны самостоятельно, просмотрев логи. Если форматирование не соответствует ожидаемому, то вам будет сказано, в каких строках кода проблемы.
| clang-format OK | clang-format !OK |
|---|---|
Если тесты на Ubuntu не отработали полностью корректно, то на Windows проверка не будет запущена. Поэтому если вы видите, что проверка завершилась неуспешно и вы не понимаете почему, то вместо того, чтобы тратить попытки на GitHub (которые у вас ограничены), лучше сразу написать проверяющему о своей проблеме.
Last updated
