Базовый модульный тест и C, как мне начать? - PullRequest
23 голосов
/ 17 января 2009

После прочтения нескольких тем здесь, в StackOverflow, Я пришел к выводу, что я должен принять в какой-то форме тест-ориентированная разработка / юнит-тест (или хотя бы исследование местности).

И так как мы говорим о c-коде под Linux, Я решил попробовать чек (Я не знаю, является ли это правильным выбором, но если это не хорошо, я всегда могу попробовать что-то еще позже).

Но так как эта концепция модульного и модульного тестирования является абсолютно новой для меня, Я начал делать какой-то модульный тест на очень маленьком тестовом коде (но я все равно был полностью потерян и мне казалось, что я что-то упустил)

Это то, что я сделал до сих пор, я создал следующий файл:

  • main.c, main, который вызывает только функцию my_pow и печатает результат.
  • my_pow.c, содержит функцию my_pow.
  • my_pow.h
  • my_pow_test.c, я решил, что я должен разместить здесь код модуля для функции my_pow.

(То есть «обычная программа» - это main.c, my_pow.c и my_pow.h.)

Это my_pow.c


#include "my_pow.h"
int my_pow(int a, int b)
{
    return (a*b);
}

Тогда я понял, что в my_pow_test.c я положил что-то вроде этого:


#include <check.h>
#include "my_pow.h"

START_TEST (test_my_pow)
{
    /* unit test code */
}
END_TEST

//do I need some sort off main here that calls test_my_pow?

Это в основном то же самое, что и в руководстве по проверке глава 3.1, но все же нет ...

Может кто-нибудь, пожалуйста, подтолкнуть меня в правильном направлении?

Спасибо Johan


Обновление: нет причин, по которым я пытался использовать проверку, я просто думал, что мне нужно с чего-то начать, может быть, CUnit - лучший выбор (думаю, я бы тоже попробовал, а затем сделал бы обоснованный выбор).

Обновление: спасибо @philippe за косвенное указание на то, что онлайновая документация - это только половина правды, Пример кода, поясняющий то, о чем говорится в документации, уже был установлен с пакетом check. В случае с Ubuntu / usr / share / doc / check / example / tests /

Обновление: пример кода был создан так, что вы начали с просмотра его первой версии, затем второй и т.д.

И так как мой код был сломан, и я хотел, чтобы модульный тест доказал это, Я немного обманул и проверил против реальной функции Pow. Примерно так:


START_TEST (test_my_pow1)
{
    int resultat = my_pow(3,3);
    int math     = pow(3,3);
    fail_unless ( resultat == math,
           "Error on 3^3 != %d (%d)",math, resultat);
}

Однако в будущем я не буду воспроизводить то, что уже есть в stdlibs: -)


Связанный:

взято из поиска [c] [unit-testing].

Ответы [ 3 ]

8 голосов
/ 17 января 2009

Вы создали первый контрольный пример. Теперь вам нужно создать набор тестов (группа тестовых случаев) и runner .

Я бы порекомендовал вам попробовать сначала скомпилировать их пример для проверки вашей среды, хотя в их документации вводится новый код через diff (исправление исходного кода), который я не нахожу очень удобным.


Если вы когда-нибудь решите попробовать другой фреймворк ( minunit сразу придет мне в голову), я могу указать вам на " учебник ".

5 голосов
/ 17 января 2009

Я был бы более склонен использовать CUnit , который является частью серии тестовых сред X-Unit.

Он масштабируется для больших наборов тестов и используется уже много лет, поэтому является зрелым.

Есть причина, почему вы не пошли с CUnit?

НТН

ура

Rob

4 голосов
/ 18 января 2009

Я использую дежагну годами и люблю это.

Я начал использовать его для разработки встроенных приложений, поскольку он очень хорошо поддерживает концепцию, согласно которой машина, на которой вы запускаете тестовую программу, может отличаться от машины, на которой вы создаете тестовую программу. Следствием этого является то, что тестирование кода на нескольких платформах также хорошо поддерживается. Не уверен, что это важно. GCC testsuite использует его. Я использую его и для разработки десктопов.

Основная идея дежагну заключается в том, что вы

  • скопировать тестовую программу в "target" (для локального тестирования это может быть каталог ~ / tmp)
  • запустить тестовую программу
  • вывод на консоль материала (который служит входом для тестовой программы)
  • парсит выходные данные тестовой программы и сопоставляет их с тем, что вы ожидаете
  • решить, будет ли этот вывод пройден или не пройден

Как только у вас есть тестовая программа и написаны тестовые сценарии, вы в конечном итоге делаете что-то вроде этого:

$ runtest
                === foo Summary ===

&#35; of expected passes            42
foo-test built Thu Jan 15 20:09:19 PST 2009
foo-test version 0.0.0.1
runtest completed at Sun Jan 18 08:29:13 2009

Я попал туда для тестирования библиотеки с именем foo:

  • предполагается, что исходные и подключаемые файлы для библиотеки находятся в ~ / src / foo
  • создать каталог с именем ~ / src / foo / testsuite
  • написать тестовую программу с именем foo-test.c, которая имеет main (), которая
  • обрабатывает аргументы командной строки
  • - печатает подсказку и сидит в цикле, обрабатывая «команды», где я определяю команду для проверки каждой функции в моей библиотеке. Это похоже на командную оболочку, но специфично для библиотеки. Для чего-то вроде my_pow я бы определил команду, принимающую 2 аргумента.
  • написать dejagnu (это еще один слой поверх Expect (http://expect.nist.gov/,, который сам является слоем поверх Tcl) (http://www.tcl.tk/) функция с именем my_pow, которая:
  • принимает два аргумента
  • вычисляет ожидаемый результат (в Tcl)
  • отправляет my_pow на консоль
  • анализирует вывод команды my_pow из foo-test
  • определяет, соответствует ли фактический результат ожидаемому.
  • вызывает соответствующую функцию dejagnu (успешно или успешно)

Звучит сложно, но это не так. Требуется некоторое время, чтобы решить, сколько работы нужно выполнить в foo-test, а сколько - в Tcl. В итоге я использую достаточное количество функций оболочки (например, bash) для таких вещей, как копирование файлов во временные каталоги или просмотр файлов журналов, которые генерируют мои программы. Таким образом, вы в конечном итоге становитесь хорошими во всем этом.

Что касается ссылок, есть одна книга по Expect, которую я бы назвал требованием для погружения в это: http://oreilly.com/catalog/9781565920903/index.html.
Между этим и онлайн-справочником команд Tcl http://www.tcl.tk/man/tcl8.4/TclCmd/contents.htm и FAQ (http://www.psg.com/~joem/tcl/faq.html), вы в значительной степени там.

Удачи.

-DB

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...