Добавление модульных тестов к [закрытому] унаследованному коду
У размотки все в порядке, за исключением того, что вы должны использовать sendto
Вот пример, который предполагает, что у вас уже есть сокет. Это было взято из Clamav
static void
broadcast(const char *mess)
{
struct sockaddr_in s;
if(broadcastSock < 0)
return;
memset(&s, '\0', sizeof(struct sockaddr_in));
s.sin_family = AF_INET;
s.sin_port = (in_port_t)htons(tcpSocket ? tcpSocket : 3310);
s.sin_addr.s_addr = htonl(INADDR_BROADCAST);
cli_dbgmsg("broadcast %s to %d\n", mess, broadcastSock);
if(sendto(broadcastSock, mess, strlen(mess), 0, (struct sockaddr *)&s, sizeof(struct sockaddr_in)) < 0)
perror("sendto");
}
5 ответов
Я обнаружил, что лучший способ - это постепенно добавлять модульные тесты, а не просто вмешиваться и говорить, что мы сейчас проведем модульное тестирование приложения.
Итак, если вы собираетесь коснуться кода, исправить ошибки или провести рефакторинг, затем сначала напишите модульные тесты. В случае ошибок модульные тесты помогут определить причину проблемы, так как вы можете ее продублировать.
В случае рефакторинга вы захотите написать модульные тесты, но вы можете обнаружить, что этот тест невозможно написать, поэтому вам может потребоваться найти высокий уровень, который вызывает функцию, которая будет реорганизована, и модульное тестирование этой части. Затем, по мере рефакторинга наступательной функции, напишите свои тесты, чтобы убедиться, что она работает должным образом.
Нет простого способа сделать это.
Этот вопрос может помочь с дополнительными предложениями. Как внедрить модульное тестирование в большую устаревшую (C / C ++) базу кода?
Книга Майкла Фезерса «Эффективная работа с устаревшим кодом» - это целая книга, посвященная этой теме. Майкл заявляет, что часто слишком сложно вводить тесты для унаследованного кода, потому что он не структурирован для тестирования. Больше всего я извлек из книги пару шаблонов под названием «Функции ростков» и «Классы ростков». Функция ростка - это функция, которая инкапсулирует изменения, которые вам необходимо внести в код. Затем вы выполняете модульное тестирование только этих функций. Класс sprout - это та же идея, за исключением того, что новая функциональность содержится в классе.
Да и вообще больно. Мне часто приходилось писать вместо этого интеграционные тесты.
В книге Искусство модульного тестирования есть несколько хороших советов по этому поводу. Он также рекомендует книгу Эффективная работа с устаревшим кодом ; Я еще не читал последний, но он у меня в стеке.
РЕДАКТИРОВАТЬ: Но да, даже минимальное покрытие кода того стоило. Это придало мне уверенности и безопасности для рефакторинга кода.
РЕДАКТИРОВАТЬ: Я прочитал «Работа эффективно с устаревшим кодом», и это превосходно.
Одной из альтернатив модульных тестов, также представленных в разделе Эффективная работа с устаревшим кодом, являются тесты характеристик . У меня были интересные результаты с такими тестами. Их проще настроить, чем модульные тесты, поскольку вы тестируете с точки, чем можно тестировать (так называемый шов). Недостатком является то, что когда тест не проходит, у вас меньше намека на локализацию проблемы, поскольку тестируемая область может быть намного больше, чем при модульных тестах. Здесь помогает ведение журнала.
Среда модульного тестирования, такая как из семейства xUnit, может использоваться для написания тестов характеристик.
В таких тестах, написанных после фактов, утверждения проверяют текущее поведение кода. В отличие от модульных тестов, они не доказывают правильность кода, они просто фиксируют (характеризуют) текущее поведение кода.
Процесс аналогичен процессу TDD:
- написать тест для части кода
- выполнить его - сбой
- исправить тест на основе наблюдаемого поведения кода
- выполнить его - pass
- repeat
Тесты завершатся ошибкой, если вы измените внешнее поведение кода. Внешнее поведение кода? звучит знакомо ? Да, вот и мы. Теперь вы можете выполнить рефакторинг кода.
Очевидно, что риск зависит от охвата характеристическими тестами.
Очевидно, что риск зависит от охвата характеристических тестов.
Очевидно, что риск зависит от охвата характеристических тестов.
Если вы планируете рефакторинг унаследованного кода, то создание этих модульных тестов является обязательным. Не беспокойтесь о насмешках или заглушках - беспокойтесь о тестировании входов и выходов системы, чтобы ваши изменения или усилия по рефакторингу не нарушили текущую функциональность.
Я не буду вам лгать, модифицируя модульные тесты для унаследованного кода сложно - но оно того стоит.