Тестируем с помощью Fitnesse+PowerSlim. Часть 3. Advanced

Часть 1. Введение 
Часть 2. База 
Часть 3. Интересные возможности (эта статья)
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест

Прошло уже достаточно много времени с момента опубликования первых двух частей (часть 1, часть 2) про использование связки FitNesse+PowerSlim. Не скажу, чтобы статьи пользовались большой популярностью. Команда время от времени меня тролила и накручивала статистику блогу. Я вас обожаю :)

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

Начну я с одного из мощнейших инструментов FitNesse - сценариев. PowerSlim поддерживает этот способ разработки тестов и в его примерах можно найти тесты использующие этот функционал.

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

Давайте попробуем прикинуть набор тестов для проверки функционала нашего продукта, который контролирует возможность запуска виртуальной машины пользователем. Для старта машины пользователь должен выполнить несколько действий:

• Аутентифицироваться на сервере авторизации и установить уровень сессии "Для служебного пользования"
• Выполнить запуск виртуальной машины

С точки зрения теста мы должны: 

• аутентифицировать пользователя, 
• установить уровень сессии, 
• попробовать запустить машину,
• проверить - машина запустилась или нет (в зависимости от теста)
• проверить, что факт попытки запуска и принятое решение (о разрешении или запрете) записаны в системе аудита
• отключить пользователя от сервера авторизации

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

Наша иерархия "кубиков"

Есть другой способ переиспользования кода тестов: подключение страниц (include page). Это можно использовать например для возможности использования PowerShell функции написанной прямо внутри страницы (хотя тут же можно использовать и сценарий). PowerShell код по вызову Win32 API функции из kernel32.dll (страшная штука сама по себе) - отличный кандидат на такой "кубик".
Вообще PowerShell функции поддерживаются в PowerSlim и это еще один способ переиспользования кода в тестах.

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

Неочевидные преимущества PowerSlim:
1. Можно запустить несколько PowerSlim серверов на разных портах на одной машине. Зачем?

• Надо иметь возможность обращаться и к 64, и к 32-битному PowerShell из теста.
• Можно запустить несколько PowerSlim под разными Windows-пользователями на одной машине. При этом все действия на удаленной машине будут идти от "первого" лица - без наложенных преобразований, которые неизбежно возникают при использовании, например, PowerShell Remoting.

2. Так как это PowerShell и соответственно .Net, то у нас есть возможность, при желании, проверять функционирование UI с помощью уже готовых библиотек, например White, UI Automation PowerShell Extensions.

3. Отлично подходит для проверки функционала распределенного продукта: например у нас в проверке пользовательских сценариев используется минимум 3 виртуальных машины. На всех трех разворачиваются компоненты нашего продукта, осуществляются необходимые настройки, действия и проверки, и все это можно делать из одного теста. Кроме этого, есть возможность выполнить какое то действие одновременно на нескольких машинах (код можно найти в примерах):

пример есть в PowerSlim сюите тестов ExampleS

4. Возможность запуска теста на нужном по сценарию количестве машин становится еще удобнее с фичей Symbols Sharing. Мы это используем в том случае, если прямо в тесте нам нужно создать виртуальную машину локально на сервере виртуализации, получить ее ID-идентификатор и использовать его при при проверке аудита на другом сервере.

пример есть в PowerSlim сюите тестов ExampleS

5. Правильно написанные тесты на FitNesse+PowerSlim дают возможность абстрагироваться от способа реализации фичи: тесту все равно какой способ аутентификации используется системой, какой транспорт используется для передачи служебной информации между компонентами тестируемой системы, какая база используется для хранения настроек, какой язык используется для написания продукт и так далее. В итоге автор тестов, большей частью, сконцентрирован на реализации проверки пользовательских сценариев. Тесты можно писать параллельно самому функционалу. Например, здесь все равно каким образом система контролирует свои файлы, тест просто удаляет файл настроек и проверяет реакцию

6. Это в свою очередь дает возможность писать тесты любому человеку знакомому с PowerShell. Это могут быть тестировщики, или сами разработчики (как у нас). Весь наш продукт написан на C++, иногда сложно переключаться между языками, но мозг тренирует. (Гусары, молчать :)

7. FitNesse+PowerSlim хорошо встраивается в Continuous Integration системы (TeamCity и Jenkins). Мы долгое время использовали готовый плагин к Jenkins (я пожалуй расскажу как-нибудь про нашу CI-систему). Но растущее количество запускаемых тестов, а также ряд проблем с этим плагином заставили нас написать свой "почти"-плагин, который закладывает результаты тестов и артефакты (логи) в базу и дает возможность быстро смотреть часть логов привязанную к конкретному тесту. Очень удобно.

Небольшое итого: 

на мой взгляд количество и качество существующих фреймворков, с помощью которых можно автоматически проверять функционал продуктов работающих на Windows-платформах, оставляет желать лучшего. Из бесплатных это, пожалуй, только Robot Framework (недавно появился неплохой guideline), FitNesse . Из известных мне платных: Visual Studio Test Professional.

К достоинству Robot Framework можно отнести его используемый язык программирования (Python, хотя есть расширения для IronPython и Jython) и, возможно, большая популярность, в сравнении с Fitnesse. Во всяком случае информации в интернете побольше будет.

Fitnesse+PowerSlim дает возможность использовать все, что есть в PowerShell - мощный инструментарий для настройки Windows, и так же сервисов Microsoft (Exchange, SharePoint, Hyper-V и тп). Для использования всего этого в Robot'e пришлось бы писать прослойки.

К недостаткам Fitnesse+PowerSlim можно отнести некоторую сложность внедрения (например, прекрасно автономно работающие PowerShell скрипты могут не работать внутри PowerSlim), неочевидность его преимуществ. Именно поэтому я решил написать эти статьи и добавить более жизненные примеры в сюиту примеров PowerSlim. Надеюсь, это поможет.

Visual Studio в редакции для тестировщиков я не рассматривал. Во-первых она платная и в нашу подписку не входит. Во-вторых, на момент внедрения автоматизации тестирования, функционал студии был достаточно слабый и в качестве платформы виртуализации использовался Hyper-V, что нам не подходит. Допускаю, что сейчас положение дел улучшилось. Но у open-source движков есть важное преимущество - их можно подтачивать под себя в случае необходимости. При этом базовые вещи уже реализованы.

Есть еще вариант в виде написания своего самописного фреймворка, очередного мегабыстрого и крутого велосипеда. Но мне такой подход не нравится: по опыту - это нерасширяемо, плохо переносимо, как правило узкоспециализированно и требует много времени. Иногда это оправдано, но чаще всего нет.

Update: Записал screencast своей презентации на работе с демо того, что у нас получилось с Fitnesse и как он интегрируется в Jenkins