Часть 1. Введение (эта статья)
Часть 2. База
Часть 3. Интересные возможности
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест
Плагин для sublime, который подсвечивает синтаксис теста на Fitnesse+PowerSlim
С Fitnesse я познакомился в 2007 году. Начинали мы его использовать совместно с .Net. Потом был Python. После некоторого перерыва, решил посмотреть, как он поживает сейчас.
Товарищи с прошлой работы познакомили с расширением, которое позволяет использовать всю мощь Fitnesse в полной мере. Время на развертывание минимально. Если вы еще и знакомы с PowerShell, то проблем и того меньше.
Итак, разговор пойдет о Fitnesse и расширении к нему PowerSlim. Название расширения намекает на использование PowerShell и технологии Slim, которая появилась в Fitnesse сравнительно недавно.
Я не буду углубляться в теоретические дебри Fitnesse'a. И не буду пытаться вас уговорить его использовать. Вместо этого, мы постараемся на простых примерах понять, как его можно использовать для проверки функционала ваших продуктов. Вдруг вам подойдет?
Jump-start :)
Для запуска Fitnesse + PowerSlim вам потребуется:
Заходим по URL http://localhost:8080 (естественно можно открыть и удаленно, если настройки firewall'а позволяют) и видим такой FrontPage
Теперь cкачиваем PowerSlim. Внутри архива вы найдете набор PowerShell скриптов и тесты-примеры использования PowerSlim. Лучше сразу разблокировать все файлы *.ps1 (они, как запускаемые, могут быть заблокированы из-за политики безопасности Windows), иначе тесты не будут запускаться.
Скрипты PowerSlim после распаковки должны лежать на одном уровне с папкой FitNesseRoot, которая создается после распаковки Fitnesse'a. Содержимое "PowerSlim-master\FitnesseRoot" (папки ExampleS и PowerSlim) переносим в основной FitNesseRoot.
Должно получиться как то так:
Заходим по URL http://localhost:8080/PowerSlim.OriginalMode.
Если все сделано правильно, то видим такую картинку
Жмем "Suite". Поздравляю, вы только что запустили тесты на Fitnesse :) и настроили машину-сервер.
Скорее всего, вам интересно запускать тесты на удаленной машине (стенде). Давайте сразу проверим, как это можно сделать. Обращаю внимание, что предполагается наличие сетевого соединения машины-сервера и стенд-машины.
На стенд-машине ставим (или активируем) PowerShell. Лучше 3.0, но можно и 2.0, если вам нужно тестировать на OS, которая не поддерживает 3-ю версию. Копируем на стенд slim.ps1 (из пакета PowerSlim) и создаем рядом с ним startRemote.cmd файл с таким содержимым:
PowerShell -ExecutionPolicy unrestricted -file .\slim.ps1 35 server
Запускаем startRemote.cmd. Это запустит tcp-сервер, который будет слушать и обрабатывать запросы с машины, на которой установлен Fitnesse.
Если на стенд-машине стоит firewall, то нужно разрешить TCP подключения с машины-сервера (или any) по 35 порту (35 из строчки в cmd это порт, по которому будет работать сервис). Порт можно поменять, но пока лучше оставить так. Для чего можно использовать возможность менять порты я расскажу в следующих постах.
Открываем страницу http://localhost:8080/ExampleS.GetService. В оригинале этот тест проверяет статус всех сервисов, у которых DisplayName есть слово "Time". Делается это локально на машине-сервере. Давайте переделаем его для проверки статусов сервисов на стенд-машине.
Жмем "Edit", видим внутреннее устройство страницы со специфичной разметкой. Меняем редактор на "plain text" (с красивым RTF-редактором у меня были проблемы с итоговым форматированием страницы).
Заменяем Query:Local на Query:Remote. Добавляем адрес или имя стенд-машины (обратите внимание на разделители '|' на картинке). Теперь "Save" и "Test".
Bingo - мы видим результат нашего первого теста на стенд-машине :)
У меня тест "красный" потому, что, кроме ожидаемого мной "Windows Time", обнаружился еще и "Hyper-V Time Synchronization Service" из-за активированной роли Hyper-V. Поправляем тест (через "Edit") и делаем его зеленым. Как? Ну или меняем запрос в получении сервисов, или добавляем новый сервис в список ожидаемых, новой строчкой. Зависит от того, что правильнее с точки зрения сценария.Чем не TDD? :)
Заметьте, мы не делали никаких дополнительных действий по настройке пермиссий, которые обычно приходится делать для настройке Remote PowerShell. Главное, чтобы у аккаунта под которым запускается сервис на стенд-машине было достаточно прав для выполнения запускаемых PowerShell команд. Подробней об этом в следующих постах.
Для начала, я думаю хватит. Что нам может дать этот инструмент? PowerShell можно использовать для получения состояния вашего продукта, состояния среды в которой он работает, и с которой взаимодействует.
Начинаем с проверки того, что сетап установил нужные файлы, создал ключи реестра, зарегистрировал сервисы. Все это доступно через PowerShell. Дальше, например, можно запускать и настраивать ваш продукт, проверять результаты его работы.
Мы у себя, к примеру, проверяем воздействие (полезное воздействие :) на виртуальную инфраструктуру, которое оказывает наш продукт. PowerShell cmdlet позволяют работать с Microsoft Hyper-V, VMware vSphere серверами и виртуальными машинами. Кроме этого, вы можете работать с Sharepoint, Exchange и AD инфраструктурами.
Все (ну или почти все) что доступно в PowerShell - доступно в Fitnesse+PowerSlim.
При этом вы получаете историю запуска тестов, возможность писать user stories/features привязанные к тестам. Тесты можно запускать руками, но это неправильно. Можно запускать автоматически и использовать cmdline - уже лучше. А можно использовать Fitnesse плагин к TeamCity и увязать ваши тесты с хорошей CI системой.
В следующих постах я расскажу про то, как писать первые тесты. Приведу примеры то, как можно проверить распространенные сценарии.
А пока вы можете посмотреть на реализацию тестов PowerSlim (http://localhost:8080/PowerSlim). Да, на сам фреймворк есть тесты! И их можно использовать как примеры. Кроме этого, есть еще тесты по URL http://localhost:8080/ExampleS (они, кстати не будут "зелеными" на вашем сервере, потому что это примеры использования).
PowerSlim - это развиваемый в настоящее время opensource проект и я думаю, что Константин будет рад ответить на ваши вопросы. Задавайте свои вопросы и здесь. Это поможет определиться с тематикой следующих постов.
Часть 2. База
Часть 3. Интересные возможности
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест
Плагин для sublime, который подсвечивает синтаксис теста на Fitnesse+PowerSlim
С Fitnesse я познакомился в 2007 году. Начинали мы его использовать совместно с .Net. Потом был Python. После некоторого перерыва, решил посмотреть, как он поживает сейчас.
Товарищи с прошлой работы познакомили с расширением, которое позволяет использовать всю мощь Fitnesse в полной мере. Время на развертывание минимально. Если вы еще и знакомы с PowerShell, то проблем и того меньше.
Итак, разговор пойдет о Fitnesse и расширении к нему PowerSlim. Название расширения намекает на использование PowerShell и технологии Slim, которая появилась в Fitnesse сравнительно недавно.
Я не буду углубляться в теоретические дебри Fitnesse'a. И не буду пытаться вас уговорить его использовать. Вместо этого, мы постараемся на простых примерах понять, как его можно использовать для проверки функционала ваших продуктов. Вдруг вам подойдет?
Jump-start :)
Для запуска Fitnesse + PowerSlim вам потребуется:
- Машина с Windows 7, 2008, 2012
- Java engine
- PowerShell 3.0, лучше сразу с Powershell ISE
- Сам Fitnesse
Заходим по URL http://localhost:8080 (естественно можно открыть и удаленно, если настройки firewall'а позволяют) и видим такой FrontPage
Скрипты PowerSlim после распаковки должны лежать на одном уровне с папкой FitNesseRoot, которая создается после распаковки Fitnesse'a. Содержимое "PowerSlim-master\FitnesseRoot" (папки ExampleS и PowerSlim) переносим в основной FitNesseRoot.
Должно получиться как то так:
Заходим по URL http://localhost:8080/PowerSlim.OriginalMode.
Если все сделано правильно, то видим такую картинку
Жмем "Suite". Поздравляю, вы только что запустили тесты на Fitnesse :) и настроили машину-сервер.
Скорее всего, вам интересно запускать тесты на удаленной машине (стенде). Давайте сразу проверим, как это можно сделать. Обращаю внимание, что предполагается наличие сетевого соединения машины-сервера и стенд-машины.
На стенд-машине ставим (или активируем) PowerShell. Лучше 3.0, но можно и 2.0, если вам нужно тестировать на OS, которая не поддерживает 3-ю версию. Копируем на стенд slim.ps1 (из пакета PowerSlim) и создаем рядом с ним startRemote.cmd файл с таким содержимым:
PowerShell -ExecutionPolicy unrestricted -file .\slim.ps1 35 server
Запускаем startRemote.cmd. Это запустит tcp-сервер, который будет слушать и обрабатывать запросы с машины, на которой установлен Fitnesse.
Если на стенд-машине стоит firewall, то нужно разрешить TCP подключения с машины-сервера (или any) по 35 порту (35 из строчки в cmd это порт, по которому будет работать сервис). Порт можно поменять, но пока лучше оставить так. Для чего можно использовать возможность менять порты я расскажу в следующих постах.
Открываем страницу http://localhost:8080/ExampleS.GetService. В оригинале этот тест проверяет статус всех сервисов, у которых DisplayName есть слово "Time". Делается это локально на машине-сервере. Давайте переделаем его для проверки статусов сервисов на стенд-машине.
Жмем "Edit", видим внутреннее устройство страницы со специфичной разметкой. Меняем редактор на "plain text" (с красивым RTF-редактором у меня были проблемы с итоговым форматированием страницы).
Заменяем Query:Local на Query:Remote. Добавляем адрес или имя стенд-машины (обратите внимание на разделители '|' на картинке). Теперь "Save" и "Test".
Bingo - мы видим результат нашего первого теста на стенд-машине :)
У меня тест "красный" потому, что, кроме ожидаемого мной "Windows Time", обнаружился еще и "Hyper-V Time Synchronization Service" из-за активированной роли Hyper-V. Поправляем тест (через "Edit") и делаем его зеленым. Как? Ну или меняем запрос в получении сервисов, или добавляем новый сервис в список ожидаемых, новой строчкой. Зависит от того, что правильнее с точки зрения сценария.Чем не TDD? :)
Заметьте, мы не делали никаких дополнительных действий по настройке пермиссий, которые обычно приходится делать для настройке Remote PowerShell. Главное, чтобы у аккаунта под которым запускается сервис на стенд-машине было достаточно прав для выполнения запускаемых PowerShell команд. Подробней об этом в следующих постах.
Для начала, я думаю хватит. Что нам может дать этот инструмент? PowerShell можно использовать для получения состояния вашего продукта, состояния среды в которой он работает, и с которой взаимодействует.
Начинаем с проверки того, что сетап установил нужные файлы, создал ключи реестра, зарегистрировал сервисы. Все это доступно через PowerShell. Дальше, например, можно запускать и настраивать ваш продукт, проверять результаты его работы.
Мы у себя, к примеру, проверяем воздействие (полезное воздействие :) на виртуальную инфраструктуру, которое оказывает наш продукт. PowerShell cmdlet позволяют работать с Microsoft Hyper-V, VMware vSphere серверами и виртуальными машинами. Кроме этого, вы можете работать с Sharepoint, Exchange и AD инфраструктурами.
Все (ну или почти все) что доступно в PowerShell - доступно в Fitnesse+PowerSlim.
При этом вы получаете историю запуска тестов, возможность писать user stories/features привязанные к тестам. Тесты можно запускать руками, но это неправильно. Можно запускать автоматически и использовать cmdline - уже лучше. А можно использовать Fitnesse плагин к TeamCity и увязать ваши тесты с хорошей CI системой.
В следующих постах я расскажу про то, как писать первые тесты. Приведу примеры то, как можно проверить распространенные сценарии.
А пока вы можете посмотреть на реализацию тестов PowerSlim (http://localhost:8080/PowerSlim). Да, на сам фреймворк есть тесты! И их можно использовать как примеры. Кроме этого, есть еще тесты по URL http://localhost:8080/ExampleS (они, кстати не будут "зелеными" на вашем сервере, потому что это примеры использования).
PowerSlim - это развиваемый в настоящее время opensource проект и я думаю, что Константин будет рад ответить на ваши вопросы. Задавайте свои вопросы и здесь. Это поможет определиться с тематикой следующих постов.
Хорошая вещь - Fitnesse, хочется продолжения с примерами применения :)
ОтветитьУдалитьГотовлю уже. На самом деле много примеров уже в самих тестах PowerSlim. Надо их просто к жизни развернуть.
ОтветитьУдалитьВопрос из взбаламученной народной массы: как быть с параллельным выполнением?
ОтветитьУдалитьДопустим, есть тесты в виде трёъ стадий A1A2A3 (A1 - подготовка данных, A2 - процессинг данных, то, что делает продукт и надо тестировать, A3 - обработка результатов). Соответственно, B1B2B3,...,N1N2N3,.....Z1Z2Z3.
Практика показывает, что выгодно выполнять вместе A2,B2,...,N2,...,Z2 (просто за одну обработку данных можно обработать много разных типов данных, а обработка время занимает).
Отсюда имеет смысл готовить данные сразу для A1,B1,...,N1,...,Z1 шагов и совместно же проверять результаты A3,B3,...,N3,...,Z3.
Как это размещать в фитнессе? Размещать по тестам A1A2A3, B1B2B3 не выгодно - время на тест умножается почти на кол-во тестов.
Саша, в лоб ответить сложно. Ближе к жизни можно пример? Потому что в теоретических изысканиях, можно еще и не такое придумать. На моей практике не было такой необходимости. Тут же главное не забывать про то, что тесты не должны друг другу мешать и должны запускаться независимо. Но вообще, PowerSlim позволяет запускать команды одновременно на нескольких хостах. То есть должна работать запись вида (имена серверов через запятую, и пока без пробелов)
ОтветитьУдалить|script|remote|server1,server2|
|eval|cmdToRun|
Аналогично должно (судя по коду slim.ps1) работать и Query. Но я пока не использовал. Это вам поможет?
Макс, разделение тестов хорошо, но у нас тут оно реализовано через разделение входных данных и результатов: подаётся пачка входных данных, потом работает продукт, потом полученные данные сравниваются с входными (и правилами).
ОтветитьУдалитьЕсли ради каждого теста запускать процессинг, это накладно.
Что касается параллельного выполнения - в простом случае это же просто один и тот же код выполняется в разных лабах, разве нет?
Будем думать, потому что сейчас это тоже неудобно, если хочется запустить совсем мало тестов для отладки.
А как насчёт задания переменных?
ОтветитьУдалитьЕсли надо задать хост вверху таблицы или результат для сравнения, то тут надо задать переменную фитнесом (define).
И задаётся это, к примеру, на страничке типа suite.
Если надо задать значение в пауэршельный код, то тут подойдёт пауэршельная переменная (потому что код заэскейплен !- -! и эскейпы внутри кода недопустимы: а как его дебажить, каждый копи-пейст станет пыткой).
И задаваться эти переменные могут только на страничке типа test, потому что она исполняемая.
Получается, что переменные заданы в двух местах, да ещё и в каждой табличке надо юзать переменные и того, и дрйгого типа (фитнессе и пауэршелл).
Какие есть солюшены у передовиков фитнессо-строения по этому поводу?
Да, один скрипт будет выполняться на разных лабах.
ОтветитьУдалитьмогу предложить организовывать большие PS скрипты в сценарии, а настройку делать через их параметры, дабы избежать проблем с дебагом и эскейпом. Итого имеем "чистые" PS скрипты без включения в них fitnesse переменных. А при вызове сценария в качестве параметра передаем fitnesse переменную.
ОтветитьУдалитьС разными лабами есть другое ограничение: можно запустить слим-клиента под разными кредами на разных хостах, но нельзя передать разные креды для тестов.
ОтветитьУдалитьТ.е., в таблице можно задать несколько хостов, на каждом хосте омжно задать под кем стартует слим-клиент.
Но вот беда - если есть массив кредов (скажем, массив имён и массив паролей), как сделать так, чтобы хосты расхватали массив по элементику?
Похоже, что так сильно проще: дело в том, что если выполняется более-менее размерный скрипт (строчек двадцать), у скрипта несколько аутпутов. И где-то посреди скрипта происходит эксепшн (неважно, хотим мы выполнять код дальше или нет).
ОтветитьУдалитьК строке таблицы вида | show | eval | многа_кода | прирастает столбец, говорящий, что .ToString() привинтить не к чему. Это вместо толкового эксепшена.
Нужный эксепшн где-то теряется и не выводится.
на удаленных хостах запускается по 1-му "управляющему" слим-серверу (я бы его называл сервером, а не клиентом) с портом по умолчанию. а дальше через него через eval запускаются вспомогательные с указанием порта и кредов под которыми запускаться. дальше тесты уже работают с поднятыми вспомогательными серверами запуская скрипты ремоутно с указанием нужного порта и код тестов будет выполняться в контексте заданном кредами.
ОтветитьУдалитьА передастся ли код скриптов "по воздуху" (по слим-протоколу) или придётся раскидывать их по каждому слим-клиент хосту (не особо большая проблема, правда, подкачать версию скриптов).
ОтветитьУдалитькод реализующий сценарии передается "по воздуху" :)
ОтветитьУдалитьЯ имел в виду не те креды, под которыми работает слим-клиент.
ОтветитьУдалитьТипичный юзкейс: лаба domain1 и лаба domain2.
Слим-клиенты работают под domain1\... и под domain2\...
А мне надо на каждом хосте передать как параметр domain1\user1 и domain2\user2 соответственно, ну или в едит бокс вбить. Вот как список кредов раскидать по слим-клиентам без сложного селектора в фитнес-таблице?
хмм, затрудняюсь. Но я бы не стал делать такой мега-тест на одной странице. Можно попробовать сделать заготовку, а потом ее уже использовать через include в тестовых страницах, которые будут ее настраивать нужными кредами и потом реально запускать.
ОтветитьУдалитьЯ бы не сказал, что это мега-тест :) Просто параллельная настройка продукта, который работает в своём домене и под своим юзером. Не селектор же делать switch ($hostname).
ОтветитьУдалитьМожно, конечно, подумать о нескольких мелких фитнесах, импортящих страницы с кодом или один большой фитнес, у которого есть пачка кредов, а мелкие фитнесы вызываются из большого с нужными кредами.
В общем, есть поводы поизвращаться/понастраивать :)