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

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

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

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


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

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

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

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

65 голосов | спросил Precipitous 2 J0000006Europe/Moscow 2009, 20:28:02

5 ответов


0

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

https://github.com/pester/Pester

ответил Martin Suchanek 5 Jam1000000amWed, 05 Jan 2011 00:31:57 +030011 2011, 00:31:57
0

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

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

ответил Cellfish 21 AM00000090000005031 2009, 09:21:50
0

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

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

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

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

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

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

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

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

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

ответил Draghon 25 Maypm12 2012, 18:02:58
0

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

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

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

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

ответил Mike 2 J0000006Europe/Moscow 2009, 22:32:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132