Подтвердить что ты не робот

Основные unit test и C, как мне начать?

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

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

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

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

  • main.c, основной, который вызывает только функцию 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 за косвенное указание, что онлайновая документация - это только половина правды, код примера, который разъясняет, что говорит о документации, уже установлен с пакетом проверки. В случае Ubuntu/usr/share/doc/check/example/tests/

Обновление: пример кода был создан так, что вы начали с рассмотрения его первой версии, затем второй и т.д. и т.д. Чтобы вы могли следить за тем, как он создает очень простой тестовый пример/код от ничего до чего-то полезного в традиционном TTD-способе.

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


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);
}

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


по теме:

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

4b9b3361

Ответ 1

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

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


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

Ответ 2

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

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

Любая причина, по которой вы не пошли с CUnit?

НТН

веселит,

Rob

Ответ 3

Я использую dejagnu годами и люблю его.

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

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

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

После того, как вы получили тестовую программу и написанные тестовые скрипты, вы в итоге делаете что-то вроде этого:

$ runtest
                === foo Summary ===

# 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 (pass или fail)  

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

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

Удачи.

-DB