Как сделать TDD и юнит-тестирование в powershell?

Question

С появлением MS PowerShell во всех новых серверных продуктах я начинаю (неохотно) думать, что мне нужно отнестись к этому серьезно. Частью "серьезно" является TDD. Нашли ли вы хорошие методы для модульного тестирования сценариев Power Shell?

Я нашел образцы насмешек от Mr Geek Noise - но мне бы очень хотелось что-то вроде RhinoMocks . Брайан Хартсок имеет пример выполнения тестов для строк powershell из MS Test. Немного хакерский, но, похоже, работает.

То, что я хочу, это опыт работы с Powershell TDD, который так же чист, как и на «настоящих» языках.

---

Обновление для уточнения:

Первые два ответа пытаются отвлечь меня от тестирования Powershell. Мнения интересные. Я не хочу знать, стоит ли тестировать в PowerShell. Это субъективный вопрос, который нужно задать на другом форуме. Я хочу решение для модульного тестирования PowerShell. Если вы думаете, что это плохая идея (это может быть), относитесь к ней как к веселому академическому вопросу.

• Да, языки сценариев склеивают разрозненные системы. Тем не менее, как уже указывалось, в динамическом языке также легко издеваться и ломать швы.
• Я не спрашиваю о "отладке". Отладка - чрезвычайно полезная тема. Я позволю кому-то еще спросить это.
• Может быть, сценарии PS должны быть простыми. Язык поддерживает модульность, и неизбежно, что сложные процессы будут реализованы в PS (даже если это плохая идея).
• Ответ на этот вопрос не "Вы не можете". Я могу видеть (из связанных блогов - которые являются немного старыми), что некоторые люди добились прогресса в проблеме.

Чтобы переформулировать: Как реализовать автоматизированное тестирование логики Powershell в стиле xUnit? Интеграционные тесты интересны, модульные тесты, которые нарушают зависимости, наиболее интересны.

Answer 1

Скотт Мук (Scott Muc) начал проект для облегченной BDD-инфраструктуры для PowerShell под названием Pester:

https://github.com/pester/Pester

Answer 2

PsUnit теперь обновляется с помощью фреймворка. У меня была та же проблема, что и у вас несколько месяцев назад, и я чувствовал, что PsUnit слишком большой и сложный для количества сценариев, которые мне нужно было написать, поэтому я написал свою собственную платформу модульного тестирования для PS. PS обладает такой же характеристикой характера, как и другие языки сценариев, например, python, то есть вы можете переопределять функции где угодно и когда угодно, даже с областью действия в методах тестирования, которая отлично подходит для подделки (например, насмешка). То есть, если у вас есть функция или объект, который вы хотите протестировать и который зависит от других функций, вы можете объявить их в своем методе тестирования, чтобы создать локальную ложную реализацию.

Так что по поводу того, какой тестовый фреймворк вы выберете, я бы сказал, что PS очень легко TDD. Это был мой опыт, по крайней мере.

Answer 3

Я думаю, что вы спрашиваете о "стратегии тестирования", а не конкретно о TDD, поэтому я отвечу на оба вопроса.

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

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

Маленькие заметки, которые могут помочь:

• Переключатель -whatif существует во встроенных командлетах. Также я только что узнал, что вы также можете сделать это: -whatif:$someBool - вы будете знать, когда вам это нужно.
• ISE, входящий в V2, имеет отладчик. Сладкое.
• Вы всегда можете написать собственный командлет в C # и делать там все, что хотите.

Answer 4

Мертвая дискуссия, но проблемы очень живы.

Единственное, чего я не вижу в обсуждении полезности модульного тестирования PS, учитывая его предполагаемое использование, включает модули в корпоративной системе. Представьте себе корпоративную настройку с центральным хранилищем для общих задач сетевого / файлового уровня, реализованных в PS. В этом режиме у вас есть небольшое количество разработчиков и сетевых специалистов, у каждого из которых есть слегка перекрывающиеся обязанности. Разработчик создает модуль, инкапсулирующий бизнес-логику, и его полезность сразу же подтверждается, так что другие мгновенно подключаются и включают модуль в свои собственные усилия. Модуль включен во что угодно, от одноразовых интерактивных скриптов до клиентских приложений среднего размера; Хотя некоторые могут не согласиться с вариантами использования языка сценариев оболочки, эволюция является постоянной в этой области.

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

Что касается предпочтительного подхода, я еще не принял его. PS напоминает жидкое / динамическое / проворное вещество. Содержать его в жесткой структуре, такой как то, что я видел с TDD, кажется неестественным. Однако, учитывая сценарий выше, эту цель нельзя игнорировать. Неважно, я порваюсь, извините, что трачу ваше время. Спасибо за чтение.

Answer 5

От твоего вопроса я думаю, что тебя ждет разочарование. Powershell - это просто маленький язык командной строки. Конечно, он может делать все, что может делать C #, и даже больше, но и ассемблер. Конечно, это также OO и подключено к библиотекам .NET, но так же как и C #, который намного более чистый язык.

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

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

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