Подходит ли модульное тестирование для коротких программ - PullRequest
8 голосов
/ 14 октября 2008

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

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

Большинство написанных мною программ содержат не более 200 строк и не более 10 функций. Я хочу писать большие, более способные программы в будущем. Я хочу улучшить свою практику, чтобы избежать создания хрупких, неразрешимых беспорядков. Среды программирования, в которых я работаю (Script Editor.app и Text Wrangler.app), не поддерживают автоматическое тестирование.

В том масштабе, в котором я сейчас работаю и написание процедурного (не ОО) кода , уместно ли писать модульные тесты , которые я понимаю являются:

коротких программ для проверки личности функции, прежде чем объединить их в полностью функционирующая большая программа.

Стоит ли модульных тестов сравнивать с их стоимостью при создании программ такого масштаба?

Ответы [ 9 ]

7 голосов
/ 14 октября 2008

Да. Все, что длиннее нуля, может быть проверено юнитом - обычно с хорошим эффектом.

4 голосов
/ 16 октября 2008

Сегодня это небольшой проект, завтра он станет центральным элементом вашей корпоративной инфраструктуры. Начните прямо сейчас, получите 100% покрытие кода сразу.

4 голосов
/ 14 октября 2008

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

3 голосов
/ 16 октября 2008

Юнит-тесты служат нескольким целям; наиболее очевидным является тестирование кода, чтобы определить, что он делает то, что должен делать. Но одной из других, более полезных целей является неявная документация ; если вы явно тестируете фрагмент кода для определенного поведения, становится ясно, что такое поведение ожидается, даже если оно неочевидно.

Рассмотрим простой оператор сложения. Прямо, верно? Хорошо, каково ожидаемое поведение при добавлении двух целых чисел со знаком, оба из которых> MAXINT / 2? Это MAXINT или отрицательное число?

Документирование всего этого иногда может быть громоздким; Нельзя сказать, что это не должно быть сделано, но опыт показывает, что это часто не делается. Тем не менее, явный модульный тест, который проверяет отрицательный случай вышеупомянутого случая, устраняет все сомнения; а также служит обоснованной цели регрессии, чтобы поведение не менялось с течением времени.

2 голосов
/ 14 октября 2008

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

только один из многих плюсов наличия набора тестов для фрагмента кода.

1 голос
/ 14 октября 2008

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

С более короткими программами, которые понятны, просто читая код, может быть нецелесообразно тщательно тестировать его, если у вас нет много времени. В противном случае я должен согласиться с моими коллегами здесь, что модульное тестирование имеет множество преимуществ и полезно даже для небольших проектов.

Предупреждение: следующие ссылки могут быть неприменимы, но последующее обсуждение является хорошим чтением.

В блогосфере в последнее время обсуждается вопрос о том, когда следует проводить тестирование, в частности, разработка через тестирование (TDD). Возможно, вы захотите проверить некоторые статьи, такие как эти три статьи Роя Ошерова.

1 голос
/ 14 октября 2008

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

0 голосов
/ 18 октября 2008

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

Имея это в виду, я говорю, что помимо документирования, как указано mcwafflestixlivejournalcom , модульные тесты помогут вам, только если вы не уверены на 100% в своем коде. Если взять пример оператора сложения для двух целых чисел, меня не волнует переполнение, если я добавляю возраст двух человек.

OTOH, модульные тесты заставляют вас выделять основную логику ваших программ (что делает вас более модульными) и помогают вам тестировать быстрее, чем когда-либо, если бы вы тестировали «вручную». В конце концов, не все мы Дональд Кнут.

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

0 голосов
/ 14 октября 2008

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

Если правильность вашего кода не важна, тогда нет необходимости в модульном тестировании.

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