Библиотеки и тестирование

Сборка библиотек

libtool — инструмент для кроссплатформенной сборки и тестирования библиотек.

Пример:

• lib.c

     1 #include "lib.h"
     2 
     3 int inc(int var) {
     4   return var + inc_var;
     5 }
  

• libg.c

     1 #include "lib.h"
     2 int inc_var = 1;
  

• lib.h

     1 int inc(int);
     2 extern int inc_var;
  

• main.c

     1 #include <stdio.h>
     2 #include <stdlib.h>
     3 #include "lib.h"
     4 
     5 int main(int argc, char *argv[]) {
     6         int n;
     7 
     8         if(argc < 2) {
     9           fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
    10           return 1;
    11         }
    12         
    13         n = atoi(argv[1]);
    14         printf("%d\n", inc(n));
    15 
    16  return 0;
    17 }
  

• Makefile к ним

     1 all:   inc
     2 
     3 libinc.so:     lib.c libg.c
     4        gcc -fPIC -shared $^ -o $@
     5 
     6 inc:   main.c libinc.so
     7        gcc -L. $< -linc -o $@
     8 
     9 check: inc
    10        LD_LIBRARY_PATH=`pwd` ./inc 123
    11 clean:
    12        rm -f *.so inc
  

А теперь с Libtool:

• Makefile:

     1 CFLAGS = -g -O
     2 LTFLAGS = --tag=CC
     3 
     4 all:    inc
     5 
     6 %.lo:   %.c
     7         libtool --mode=compile $(LTFLAGS) $(CC) -c $<
     8 
     9 libinc.la: lib.lo libg.lo
    10         libtool --mode=link $(LTFLAGS) $(CC) -o $@ $^ -rpath /usr/lib64
    11 
    12 inc:    main.o libinc.la
    13         libtool --mode=link $(LTFLAGS) $(CC) -o $@ $^
    14 
    15 check:  inc
    16         ./$< 123
    17 
    18 clean:
    19         rm -rf *.so inc .libs *.l? *.o
  

Особенности:

• Сборка двух вариантов библиотек

• Использование RPATH

• Использование shell-обёрток для подгрузки .so

Версионирование библиотек

Базовая статья

• -version-info current:revision:age

• Когда повышать версию?

  • current — +1 при любом вмешательстве в ABI

  • revision — +1 при каждом выпуске, не меняющем ABI, 0 при вмешательстве в ABI (т. е. изменении current)

  • age — +1 при добавлении в ABI, 0 при изменении или удалении (не должно быть больше current)

SONAME: version.minor.subminor

• Особенность библиотек: обратно совместимы при добавлении ABI, не совместимы при удалении/изменении

  • Например, добавление поля в конец структуры при определённых дисциплинах программирования на Си не ломает ABI

  • vresion = current - age

  • minor = age

  • subminor = revision

  • ⇒ Можно поддерживать несколько вариантов интерфейсов, от current - age до current

  • ⇒ «Версия» как таковая отсутствует, version растёт неравномерно

Семантическое версионирование Версия: MAJOR.MINOR.PATCH:

1. Обратно несовместимые изменения ABI (удаление / изменение сигнатур) — MAJOR++.MINOR=0.PATCH=0

2. Обратно совместимые изменения ABI 9добавление) — MAJOR.MINOR++.PATCH=0

3. Обратно совместимые багфиксы ABI и изменения, не затрагивающие ABI — MAJOR.MINOR.PATCH++

В работе:

• Можно добавлять ещё чиселок — для пре-релизов и/иили номеров сборки

• -release MAJOR.MINOR.PATCH

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

Целесообразно начать с преобразования исходного текста — это шаг №0 репозитория с примером

• в действительности — шесть шагов).

TODO возможно, в этот раз нужен пример попроще. Да хоть этот самый libinc?

Коротко о видах тестирования

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

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

• Модульное, 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: похоже, нет: в Meson любойтест — это отдельная программа, а что в ней, ему не интересно.

Check + autotools

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

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

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

  • Лицензия у него: The Unlicense

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

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

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

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. Небольшая плюшка — просмотр журнала тестирования

   • Как минимум, CK_VERBOSITY=verbose make check и  grep "" *.log

TODO добавить фикстуру

• Пример фикстуры для check

• странное для checkmk TODO а пользоваться-то этим как?

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

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

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

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

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

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

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

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

   • в частности, просто make check; cd src; gcov -o .libs libnamegen (

   • libnamegen — это название базы, собранной при make check.

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. В репозитории с домашними заданиями создать подкаталог 10_Testing и положить решение туда