Bash и разработка через тестирование
Мертвый и яд два различных понятия. Подозрительные сообщения являются сообщениями, которые могут быть прочитаны из очереди, но Ваш код не знает, как обработать его так, Ваш код дает исключение. Если это продолжается в течение некоторого времени, Вы хотите, чтобы это сообщение было помещено на другую очередь, таким образом, Ваши другие сообщения могут быть обработаны. Хороший подход для этого описан на MSDN.
устаревший закон А является сообщением, которое даже не обрабатывается очередью. Сеть повреждается или получение, компьютер MSMQ закрывается. Что-то как этот. Сообщение будет автоматически помещено на мертвую очередь через какое-то время Windows. Таким образом, желательно записать сервис, который контролирует мертвую очередь.
4 ответа
Итак, вот что я узнал :
Есть несколько тестирования фреймворков , написанных на bash и для bash, однако ...
Дело не в том, что Bash не подходит для TDD (хотя некоторые приходят на ум другие языки, которые подходят лучше), но типичные задачи, для которых используется Bash (Установка, Система конфигурации), для которых сложно писать тесты, и в особенно сложно настроить тест.
Плохая поддержка структуры данных в Bash затрудняет разделение логика от побочного эффекта, и действительно, обычно логики мало в сценариях Bash. Это затрудняет разбиение скриптов на проверяемые фрагменты. Есть некоторые функции, которые можно протестировать, но это исключение, а не правило.
Функции - это хорошо (tm), но они могут зайти так далеко.
Вложенные функции могут быть еще лучше, но они также ограничены.
в конце дня, приложив большие усилия, можно получен, но он проверит менее интересную часть кода, и сохраним основную часть тестирования как хорошее (или плохое) старое руководство
Мета: Я решил ответить (и принять) свой вопрос, потому что у меня не было возможности выбрать между Синан Унюр (проголосовало) и mouviciel (проголосовало) ответы на эти вопросы одинаково полезны и проницательны. Я хочу отметить ответ Стефано Борини , что, хотя сначала меня это не впечатлило, со временем я научился ценить его. Также были полезны его шаблоны проектирования или лучшие практики для ответа (проголосовали), упомянутые выше.
Если вы пишете код одновременно с тестами, постарайтесь использовать функции, которые не используют ничего, кроме своих параметров, и ничего не делают. t изменить окружающую среду. То есть, если ваша функция может также работать в подоболочке, то ее будет легко протестировать. Он принимает некоторые аргументы и выводит что-то в стандартный вывод или в файл, или, возможно, он что-то делает в системе, но вызывающий не чувствует побочных эффектов.
Да, вы получите большую цепочку функций, передающих некоторую переменную WORKING_DIR, которая также может быть глобальной, но это незначительное неудобство по сравнению с задачей отслеживания того, что каждая функция читает и изменяет. Включение модульных тестов - это тоже просто бесплатный бонус.
Постарайтесь минимизировать случаи, когда вам нужен вывод. Небольшое злоупотребление подоболочкой будет иметь большое значение для того, чтобы вещи были хорошо разделены (за счет производительности).
Вместо линейной структуры, где вызываются функции, задайте некоторую среду, затем вызываются другие, все в значительной степени на одном уровне , попробуйте перейти к глубокому дереву вызовов с минимальным возвращением данных. Возврат данных в bash неудобен, если вы добровольно воздерживаетесь от глобальных переменных ...
С точки зрения реализации я предлагаю shUnit .
С практической точки зрения я предлагаю не сдаваться. Я использую TDD в сценариях bash и подтверждаю, что это того стоит.
Конечно, я получаю примерно в два раза больше строк теста, чем кода, но со сложными сценариями усилия по тестированию являются хорошей инвестицией. Это особенно верно, когда ваш клиент передумал ближе к концу проекта и изменил некоторые требования. Набор регрессионных тестов очень помогает в изменении сложного кода на bash.
Если вы кодируете bash-программу, достаточно большую, чтобы требовать TDD, вы используете неправильный язык.
Я предлагаю вам прочитать мой предыдущий пост о передовых методах программирования на bash, вы, вероятно, будете найдите что-нибудь полезное, чтобы сделать вашу программу bash тестируемой, но мое утверждение выше остается.
Шаблоны проектирования или лучшие практики для сценариев оболочки