Базовый модульный тест и C, как мне начать?
Прочитав несколько тем здесь, в 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 руководство по проверке, но все же нет ....
Может ли кто-нибудь подтолкнуть меня в правильном направлении?
Спасибо Йохан
Обновление: нет причин, по которым я пытался использовать проверку, я просто подумал, что должен с чего-то начать, возможно, CUnit - лучший выбор (думаю, я бы тоже попробовал это, а затем сделал бы осознанный выбор).
Обновление: спасибо @philippe за косвенное указание на то, что онлайн-документация - это только половина правды, пример кода, поясняющий, о чем говорится в документации, уже был установлен вместе с пакетом проверки. В случае 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
- Как протестировать код C
- Фреймворки модульного тестирования для C
- Фреймворки тестирования для C
- Базовый модульный тест и C, как мне начать?
взято из поиска [c] [unit-testing].
@Aif, я думаю, он знает. Но чтобы увидеть и изучить возможности модульного тестирования, неплохо начать с функции, в которой есть ошибки.
Ответы 3
Я был бы более склонен использовать CUnit, который является частью серии тестовых фреймворков X-Unit.
Он масштабируется до больших наборов тестов и используется много лет, следовательно, зрелый.
По какой причине вы не выбрали CUnit?
HTH
ваше здоровье,
Роб
Вы создали первый тестовый пример. Теперь вам нужно создать набор тестов (группа тестовых случаев) и бегун.
Я бы порекомендовал вам сначала скомпилировать их пример для проверки вашей среды, хотя их документация вводит новый код через diff (исходный патч), что я считаю не очень удобным.
Если вы когда-нибудь решите попробовать с другим фреймворком (minunit пришло мне в голову сразу), я могу указать вам на «руководство».
Ссылки выше уже не актуальны ... используйте вместо этого: тестирование, бегун
Я использую Дежагну много лет, и мне он очень нравится.
Я начал использовать его для встраиваемой разработки, потому что он очень хорошо поддерживает концепцию, согласно которой машина, на которой вы запускаете тестовую программу, может отличаться от машины, на которой вы собираете тестовую программу. Следствием этого является то, что код тестирования на нескольких платформах также хорошо поддерживается. Не уверен, что это важно. Gcc testsuite использует его. Я также использую его для разработки настольных компьютеров.
Основная идея dejagnu заключается в том, что вы
- скопируйте тестовую программу в "цель" (которая для локального тестирования может быть каталогом ~ / 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 (прошла или не прошла)
Звучит сложно, но это не так. Требуется некоторое время, чтобы решить, сколько работы нужно сделать в 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
вы знаете, что pow (a, b)! = a * b? ;-)