Модульный тест Connundrum - PullRequest
4 голосов
/ 26 мая 2009

Я рассматриваю юнит-тестирование как средство регрессионного тестирования в проекте.

Однако моя проблема в том, что проект в основном представляет собой прославленную команду DIR - он выполняет тесты регулярных выражений и фильтры MD5 для результатов и позволяет указывать множество критериев, но все это предназначено для обработки ввода из система, на которой он работает.

Я также являюсь командой разработчиков из одного человека, и я подвергаю сомнению ценность теста для написанного мной кода, написанного мной.

Стоит ли модульное тестирование в этой ситуации? Если да, то как можно проводить такие испытания?

РЕДАКТИРОВАТЬ: функции MD5 и Regex не предоставлены мной - они предоставляются библиотекой Crypto ++ и Boost соответственно. Поэтому я не получаю много, тестируя их. Большая часть кода, который у меня есть, просто передает данные в библиотеки и распечатывает результаты.

Ответы [ 8 ]

4 голосов
/ 26 мая 2009

Значение test-after, как вы и просите, действительно может быть ограничено в определенных обстоятельствах, но путь к модульному тестированию из описания будет заключаться в том, чтобы изолировать тесты регулярных выражений и фильтры MD5 в одном разделе кода. и абстрагируйте подачу входных данных так, чтобы при производстве они поступали из системы, а во время модульного теста ваш тестовый класс проходил в этих входных данных.

Затем вы собираете выборку различных сценариев, которые вы намереваетесь поддерживать, и вводите их с помощью различных модульных тестов, которые осуществляют каждый сценарий.

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

3 голосов
/ 26 мая 2009

Стоит ли модульное тестирование в этой ситуации?

Не обязательно: особенно для команды, состоящей из одного человека, я думаю, что может быть достаточно автоматизировать тестирование чего-то большего, чем «единица» ... подробнее на " Если нужно протестировать внутреннюю реализацию, или только проверить публичное поведение? "

1 голос
/ 26 мая 2009

Значение регрессионного тестирования часто не осознается, пока оно не автоматизировано. Как только это будет сделано, все станет намного проще.

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

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

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

Чем больше вы можете автоматизировать это, тем лучше, даже будучи командой разработчиков из одного человека.

1 голос
/ 26 мая 2009

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

0 голосов
/ 26 мая 2009

Я подвергаю сомнению ценность теста для написанного мной кода, написанного мной

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

0 голосов
/ 26 мая 2009
  1. Ценно ли юнит-тестирование в сценарии с одним человеком? Абсолютно! Нет ничего лучше, чем возможность рефакторинга вашего кода с абсолютной уверенностью, что вы ничего не сломали.

  2. Как мне проверить это модулем? Подделать системные вызовы, а затем проверить остальную часть вашей логики.

0 голосов
/ 26 мая 2009

Целесообразно провести интеграционный тест с файловой системой. Просто убедитесь, что он делает то, что ему нужно.

0 голосов
/ 26 мая 2009

Когда вы писали код, тестировали ли вы его на ходу? Эти тесты могут быть записаны в автоматизированном сценарии, так что, когда вам нужно будет внести изменения через 2 месяца, вы можете перезапустить все эти тесты, чтобы убедиться, что вы не регрессировали.

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

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