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

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

• Модульное: тысячи их

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

  • Немного терминологии
  • Runner: кто запускает тесты
  • Иерархия test → case → suite

    • Каждый test может завершиться успехом или неуспехом

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

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

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

Check

Check:

• ЯП — C

• Поддержка TAP и др.

• Поддержка pkgconfig (⇒ autotools, cmake и т. п.)

• Поддержка в Autotools

  • в документации check

• Поддержка CMake

• Meson: непонятно ☹ TODO

Check + autotools

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

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

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

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

0. Предварительные шаги

   • Импорт, организация autotools-проекта и выделение кода библиотеки в отдельный файл

   • Сборка библиотеки и программы с ней, используется Libtool

   • TODO больше про libtool

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

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

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

   • сайт, документация

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

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

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

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

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

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

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

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

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

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

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

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

CMake / CTest / …

(Не успеем)

• CMake: add_tests

• CMake + check: CMake + check

• CMAke + CTest: короткая статья, в документации, руководство

• CMake + CTest + coverage: в документации, в руководстве по CTest

Meson / Gcovr

(Не успеем)

• -Db_coverage=true на этапе configure (абзац в документации Meson)

• Gcovr — python-обёртка над gcov

Д/З

0. Изучить выбранный вами фреймворк тестов для Си

   • Например, check, autotools и пример из лекции

     • В ALT Linux понадобятся:

       • make, automake, autoconf

       • libtool

       • libcheck-devel, check

       • (кажется, всё?)

1. Взять за основу Growable Memory Buffers for C99

   • Превратить в библиотеку

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

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

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

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

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

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

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

   • Сделать примитивную поддержку проверки покрытия (чтобы проценты показывало)

2. В репоизтории с домашними заданиями создать подкаталог 09_Testing и положить решение туда