Излишне ли запускать юнит-тест с Valgrind? - PullRequest
33 голосов
/ 20 января 2009

Всего несколько дней назад я начал изучать фреймворк модульного тестирования, который называется check, и я собираюсь запустить тест на c-коде под Linux.

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

Но скажем, я хочу протестировать динамическую структуру памяти с большим количеством свободных от malloc и и оказывается, что я могу вставить данные и снова получить правильные данные. Но это не доказывает, что я не сломал память в процессе, скажем, я забыл освободить половину памяти и потерял указатели (классический memleak). Этот код, вероятно, пройдет большую часть модульного тестирования.

Итак, теперь вопрос: это хорошая идея запустить весь код модульного теста с т. е. Valgrind и позволить ему обнаружить какие-либо проблемы с malloc / free? (Или, может быть, скомпилировать что-то вроде Electric Fence?)

Это похоже на хорошую идею, но я не уверен, к чему я клоню ... ..... 1009 *

Спасибо Johan


Обновление: Спасибо Дугласу и Джонатану, похоже, это хорошая идея, и я должен продолжить: -)

Обновление: Valgrind - забавный инструмент, но я обнаружил первые утечки памяти, которые сделали это был в тестовой среде, а не в моем собственном коде (довольно забавно, хотя). Итак, совет остальным - убедиться, что используемая вами среда модульного тестирования не протекает, прежде чем перевернуть свой собственный код вверх дном. Пустой тестовый кейс был все, что было нужно в моем случае, с тех пор работает только модуль модульного тестирования.

Ответы [ 2 ]

53 голосов
/ 20 января 2009

Мы, конечно, делаем - намного проще запустить valgrind для модульных тестов, чем с полной программой.

Кроме того, любые ошибки памяти локализуются в той области кода, которую тестирует модульный тест, что облегчает их исправление.

Плюс проверка того, что вы исправили это проще - потому что вы запускаете модульное тестирование, а не более сложный тест для вашей полной программы.

Если вы используете valgrind в автоматическом режиме, вы, вероятно, захотите --error-exitcode=<number> [default: 0]

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

http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts

10 голосов
/ 20 января 2009

Как сказал Дуглас Лидер, стоит провести ваши юнит-тесты с любым диагностическим программным обеспечением, которое вы можете взять на руки, чтобы убедиться, что оно действительно работает так, как вы ожидаете. Это включает в себя не злоупотребление памятью, поэтому использование valgrind - хорошая идея.

Вы действительно хотите, чтобы ваши модульные тесты доказали, что ваш код работает.

Вам не нужно постоянно запускать их под valgrind - но это должно быть как можно проще, и вы должны делать это периодически (например, после больших изменений).

...