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

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

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

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

Обновление, чтобы уточнить:

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

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

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

 D3vtr0n21 нояб. 2012 г., 21:33
Никогда не принимайте Powershell легко. Это невероятно мощный с минимальным кодом.
 stej17 июн. 2009 г., 12:06
посмотри наstackoverflow.com/questions/1004424/... есть похожий вопрос с некоторыми ссылками (пост PSUnit и Ли Холмс)

Ответы на вопрос(5)

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

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

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

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

 Precipitous02 июн. 2009 г., 21:42
Я предполагаю, что сценарии PowerShell будут написаны, потому что MS настаивает на этом. Это быстро станет полезным. Поскольку сценарии PS будут написаны, и они будут программами (какими бы скромными они ни были), я хочу, чтобы они были надежными. Итак, я хочу проверить их. Вы можете не согласиться, но тогда давайте назовем это академическим упражнением: как бы вы проверили юнит-тестирование сценария PowerShell? Практический вывод может состоять в том, что это слишком сложно (я думаю, что это невозможно), и я должен вместо этого использовать IronPython для сценариев, если я настаиваю на качестве. :)
 Precipitous02 июн. 2009 г., 23:44
Я использую PS как минимум 3 года для повседневной работы (в основном для надежных файловых возможностей) - теперь мы можем поговорить :) Я согласен, что это некрасиво. Тем не менее, он зацепляет много функциональности. Сюрпризы почему я хочу проверить это.
 knut20 сент. 2012 г., 13:37
Я люблю PowerShell, и чем больше я его использую и узнаю о нем, тем больше он мне нравится! Я думаю, что есть хорошие люди вроде меня. И не забывайте, что PowerShell - теперь большая часть Visual Studio в формеКонсоль диспетчера пакетов NuGet.
 Mike02 июн. 2009 г., 23:29
Никто не сомневается, что TDD в Powershell возможен. Это определенно возможно, в конце концов, Powershell может делать все, что может делать C #, а затем и некоторые другие. Функциональная природа Powershell в теории может сделать его даже лучшим языком тестирования, чем C #. Проблема только в том, что синтаксис и общий дизайн Powershell ... ну, некрасиво и удивительно. Давайте поговорим снова после того, как у вас был год опыта с этим ...
 Mike03 июн. 2009 г., 03:21
Кстати, всякий раз, когда я задаю вопрос о Powershell, я также склоняюсь к получению ответов, в которых говорится, что я не использую Powershell, и редко получаю реальный ответ, поэтому я понимаю, что это раздражает. Так сожалею об этом! И есть случаи, когда Powershell - ваш единственный вариант, например, на сайтах клиентов.

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

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

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

 Chris Oldwood06 нояб. 2013 г., 15:35
Это звучит несколько похоже на то, о чем я писал в блоге пару лет назад под заголовком «PowerShell & .Net - Построение систем как инструментария» -chrisoldwood.blogspot.co.uk/2011/11/..., Я написал много клея в PS, и мне было бы удобнее, если бы я мог тестировать его модульно - особенно обработку ошибок, поскольку это часто трудно симулировать в тестовой среде.
Решение Вопроса

Shell под названием Pester:

https://github.com/pester/Pester

 Precipitous29 янв. 2011 г., 22:45
Гораздо приятнее дизайн, чем PsUnit. Не требует никаких действий с профилями или установщиками. Я включил это и начну использовать это на этой неделе.
 Michael Sorens22 дек. 2015 г., 20:17
Я написал серию из трех частей о TDD для PowerShell, используя также Pester - смотритеПрактическое модульное тестирование PowerShell
 Ameer Deen04 июл. 2011 г., 03:22
Вот статья в блоге Скотта о Пестереscottmuc.com/blog/development/...
 Scott Muc01 мар. 2011 г., 05:19
Хех, спасибо за отзыв и плагин!

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

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

 Ian Patrick Hughes05 нояб. 2011 г., 23:50
PsUnit довольно сладкий и легкий.

что вы спрашиваете о «стратегии тестирования» вместо конкретно TDD, поэтому я отвечу на оба вопроса.

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

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

Небольшие заметки, которые могут помочь:

-whatif Переключатель существует на встроенных командлетах. Также я только что узнал, что вы можете сделать это:-whatif:$someBool - вы будете знать, когда вам это нужно.ISE, прибывающий в V2, имеет отладчик. Сладкий.Вы всегда можете написать собственный командлет в C # и делать там все, что захотите.
 Peter Seale03 июн. 2009 г., 00:06
Возможно, я предполагаю, но кого это волнует? Какое значение знать, что вы ввели «\\ server \ fileshare» и в своем тесте, и в своем скрипте? Вы либо будете чрезмерно указывать взаимодействия с внешними командлетами, либо будете тестировать взаимодействия только в своей собственной системе (которая в конечном итоге станет ОЧЕНЬ малой частью вашего сценария.) Полагаю, это имеет значение, но опять же, вы пожнете гораздо большая выгода от проведения реального тестирования в промежуточной среде (и в самом Prod, если это возможно).
 Precipitous02 июн. 2009 г., 23:23
Хм ... ты тоже сомневаешься, что это возможно. Обратите внимание, что блог Geek Noise демонстрирует решение для насмешек (разрозненные системы).
 Precipitous22 авг. 2009 г., 21:11
Ни системное, ни модульное тестирование не дают «гораздо большей выгоды» - и то, и другое необходимо. Если я тестирую «взаимодействия с внешними командлетами», это не модульный тест. Вот тривиальный пример общей логики, которая выигрывает от модульного тестирования / моделирования: у нас есть сценарий после развертывания, который выявляет интересные ошибки в журнале событий Windows - исключая спам. Шикарный здесь превосходный - нет необходимости в командлете. Критерии фильтра сложны и деликатны. Извлеките критерии где-объекта, чтобы функционировать и проверить различные входные данные. Легко придумать другие примеры.

Ваш ответ на вопрос