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

Скотт Мук начал проект легкого фреймворка BDD для PowerShell под названием Pester:

https://github.com/pester/Pester

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

Итак, независимо от того, какую среду тестирования вы решите использовать, я бы сказал, что PS очень легко превратить в TDD. По крайней мере, это был мой опыт.

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

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

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

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

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

Мертвая дискуссия, но опасения живы.

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

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

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

Я пишу несколько базовых сценариев PowerShell с TDD, как в следующей модели:

Во-первых, спецификация в SUT_spec.ps1:

Import-Module -Name .\my_SUT.ps1

$case1_input=@{}
$case1_output=@{}
f1 $case1_input $case1_output

$case1_result = $case1_output["Output"] -eq "expected"
"f1 case1: $case1_result"

# repeat for all test cases

Remove-Module -Name my_SUT

Во-вторых, мой модуль (SUT) как функция в файле my_SUT.ps1:

function f1($the_input, $the_output)
{
    #take input from $the_input hashtable, process it and put output into $the_output hashtable.

    $the_output["Output"]="results"
}

В-третьих, готовая к выпуску основная точка входа в виде отдельного файла, такого как SUT_spec.ps1, но с входными данными из реальных внешних источников.

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

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

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

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