Различия между версиями 10 и 11
Версия 10 от 2021-11-26 16:22:14
Размер: 8431
Редактор: FrBrGeorge
Комментарий:
Версия 11 от 2021-11-28 15:28:04
Размер: 8479
Редактор: ArsenyMaslennikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 73: Строка 73:
 * [[https://mesonbuild.com/Unit-tests.html#coverage|абзац в документации Meson]]  * `-Db_coverage=true` на этапе configure ([[https://mesonbuild.com/Unit-tests.html#coverage|абзац в документации Meson]])

Тестирование

  • модульное → системное → (интеграционное) → приёмочное
  • Модульное: тысячи их

  • Модульное, XUnit

    • Немного терминологии
    • Runner: кто запускает тесты
    • Иерархия test → case → suite
      • Каждый test может завершиться успехом или неуспехом

      • Если все тесты из case успешны, нечто считается оттестированным

      • Для разных случаев / подсистем / etc некоторые случаи объединяются в suit

    • Fixture: подготовка (set up) и последующая ликвидация (tear down) окружения, которое нужно тестировать
      • (например, изготовление специальных тестовых объектов)
  • Coverage: насколько полно оттестирована программа
  • Системное и далее — слишком много методологий
  • CI — не рассматриваем, хотя, возможно, стоило бы

Check

Check:

Check + autotools

Репозиторий с примером

  • За основу взят https://github.com/skeeto/fantasyname/tree/master/c

    • (это довольно безумная генерилка несуществующих имен с непростым синтаксисом шаблонов)
    • Автор — адепт учения «include-библиотеки», придётся превратить в классическую библиотеку

Этапы разработки:

  1. Предварительные шаги
  2. Простой тест. Здесь и далее раннером работает shell-perl-… начинка ./test-driver, поставляемая с autotools.

  3. Тест переписан на libcheck.

  4. Тест ещё раз переписан на использование checkmk

  5. Авторские тесты удалены из основной прогарммы и переписаны на checkmk

    • Поскольку runner-ом у нас всё ещё работает ./test-driver, с его точки зрения это один тест, все подробности про внутренние suite и cases libcheck-а ему неизвестны.

    • TODO Возможно, стоит прикрутить к этому Test_Anything_Protocol, поддержка есть и в autotools, и в check

  6. Небольшая плюшка — просмотр журнала тестирования

Тестовое покрытие

Покрытие кода

  • Запускаются все тесты со сбором статистики:
    • Какие строчки кода сколько раз выполнялись
    • В какую сторону и сколько раз ветвились условия
    • … (см. по ссылке)
  • Составляется БД с этой статистикой
  • Инструменты анализа и просмотра
    • Самый частый критерий: проценты покрытия кода

Опять-таки тысячи их, посмотрим GCov

  • Встроен в gcc ⇒ требует специальной пересборки

    • Понятно, что эксплуатировать такие бинарники не надо

В тестовом репозитории:

  1. Поддержка gcov

CMake / CTest / …

(Не успеем)

Meson / Gcovr

(Не успеем)

Д/З

  1. Изучить выбранный вами фреймворк тестов для Си
    • Например, check, autotools и пример из лекции

      • В ALT Linux понадобятся:
        • make, automake, autoconf

        • libtool

        • libcheck-devel, check

        • (кажется, всё?)
  2. Взять за основу Growable Memory Buffers for C99

    • Превратить в библиотеку
      • (!) Функция в ней всего одна, остальное макросы, и переделывать это не надо

      • Все макросы уезжают в .h-файл

    • Приложение-пример можно не писать

    • Тесты взять из авторского файла tests.c

      • Тесты на память с setjmp() можно выкинуть.

    • Оформить их сообразно правилам фреймворка в несколько отдельных тестов
      • <!> (необязательно) попробовать добиться как можно более полного покрытия (предельные тексты, например, с помощью prlimit)

    • Сделать примитивную поддержку проверки покрытия (чтобы проценты показывало)
  3. В репоизтории с домашними заданиями создать подкаталог 09_Testing и положить решение туда

LecturesCMC/LinuxApplicationDevelopment2021/09_Testing (последним исправлял пользователь ArsenyMaslennikov 2021-11-28 15:28:04)