rorikstr/s21_tetris
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update from 14

Browse source
This commit is contained in:
Administrator 2024-08-14 14:53:39 +00:00
parent 0eb7f0b1c0
commit fcd73c9b90
8 changed files with 39 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

28
materials/instructions_for_testing_rus.md
View file

@ -1,13 +1,9 @@
# Инструкция по запуску тестов.
# Инструкция по запуску тестов
Помимо тестов на корректные выходные данные система автотестирования будет проверять твою программу и ее исходный код по
следующим пунктам:
Помимо тестов на корректные выходные данные система автотестирования будет проверять твою программу и ее исходный код по следующим пунктам:
* **Стилевые тесты.** Чтобы проверить, насколько красота твоего кода соответствует стандартам, ты можешь протестировать
свой код с помощью утилиты _clang-format_. В папке ```materials/linters``` лежит файл ```.clang-format```, который
содержит необходимые настройки для стилевого теста. Данный конфигурационный файл распространяет свое действие на все
файлы, которые лежат с ним в директории или в директориях ниже. Поэтому, чтобы данные настройки применились к твоим
файлам с исходным кодом, скопируй ```.clang-format``` в папку ```src```. \
* **Стилевые тесты.** Чтобы проверить, насколько красота твоего кода соответствует стандартам, ты можешь протестировать свой код с помощью утилиты _clang-format_. В папке ```materials/``` лежит файл ```.clang-format```, который содержит необходимые настройки для стилевого теста. Данный конфигурационный файл распространяет свое действие на все файлы, которые лежат с ним в директории или в директориях ниже. Поэтому, чтобы данные настройки применились к твоим файлам с
исходным кодом, скопируй ```.clang-format``` в папку ```src```. \
\
Чтобы запустить проверку на стиль, выполни следующую команду: \
```clang-format -n src/sourcefile_name.c``` \
@ -24,18 +20,13 @@
Google Style: https://google.github.io/styleguide/cppguide.html
* **Тест на корректную работу с памятью.** При написании C-программ очень важно следить за утечками памяти. Для этого в
Unix-подобных операционных системах довольно часто используют утилиту _valgrind_. Однако, на OS X имеются проблемы с
поддержкой _valgrind_, поэтому вместо нее можно использовать утилиту _leaks_. Вдаваться в механизм работы этих утилит
* **Тест на корректную работу с памятью.** При написании C-программ очень важно следить за утечками памяти. Для этого в Unix-подобных операционных системах довольно часто используют утилиту _valgrind_. Однако на OS X имеются проблемы с поддержкой _valgrind_, поэтому вместо нее можно использовать утилиту _leaks_. Вдаваться в механизм работы этих утилит
мы сейчас не будем — если интересно, можешь почитать в гугле.
**_LEAKS_**
Чтобы запустить свой исполняемый файл с помощью этой утилиты, набери в терминале: \
```leaks -atExit -- ./main.out | grep LEAK:```
Обрати внимание на команду ```| grep LEAK:```. Мы используем ее для короткого вывода, чтобы видеть только линии с
утечками, если они есть. Если ты хочешь увидеть весь вывод, просто удали эту команду.
Обрати внимание на команду ```| grep LEAK:```. Мы используем ее для короткого вывода, чтобы видеть только линии с утечками, если они есть. Если ты хочешь увидеть весь вывод, просто удали эту команду.
При запуске исполняемого файла с помощью _leaks_ может появиться сообщение об ошибке:
> dyld: could not load inserted library ‘/usr/local/lib/libLeaksAtExit.dylib’ because image not found
@ -48,8 +39,7 @@
```
_Дополнительно:_ \
Используй флаг ```-exclude``` утилиты _leaks_ для того, чтобы отфильтровать утечки в функциях, где известно об
утечках памяти. Этот флаг позволяет уменьшить количество посторонней информации, сообщаемой _leaks_.
Используй флаг ```-exclude``` утилиты _leaks_ для того, чтобы отфильтровать утечки в функциях, где известно об утечках памяти. Этот флаг позволяет уменьшить количество посторонней информации, сообщаемой _leaks_.
**_VALGRIND_**
@ -62,6 +52,4 @@
Не рекомендуется использовать _valgrind_ на OS X, вместо нее лучше использовать _leaks_.
* **Тест сборки.** Программу можно проверить на корректность сборки на тестовой системе. Для этого потребуется
установленный _Docker_. Если на системе есть докер, то можно зайти в директорию `materials/build` и запустить оттуда
скрипт run.sh. Скрипт обернет твое решение в докер и запустит его вместе с типовым сценарием сборки.
* **Тест сборки.** Программу можно проверить на корректность сборки на тестовой системе. Для этого потребуется установленный _Docker_. Если на системе есть докер, то можно зайти в директорию `materials/build` и запустить оттуда скрипт run.sh. Скрипт обернет твое решение в докер и запустит его вместе с типовым сценарием сборки.