К основному контенту

Тестируем с помощью Fitnesse+PowerSlim. Часть 1. Введение.

Часть 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 вам потребуется:
Первый запуск "java -jar fitnesse-standalone.jar" распакует содержимое архива в текущую директорию, повторный запускает сервис. Для второго запуска лучше использовать "java -jar fitnesse-standalone.jar -p 8080", где 8080 - порт, по которому сервис будет доступен. Обратите внимание: текущей директорией должна быть папка, где живет запускаемый вам fitnesse-standalone.jar.

Заходим по 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 проект и я думаю, что Константин будет рад ответить на ваши вопросы. Задавайте свои вопросы и здесь. Это поможет определиться с тематикой следующих постов.

Ссылки:
Fitnesse
PowerSlim
Для желающих подключить Python или C++:
плагины к фитнесу

Продолжение

Комментарии

  1. Сергей Атрощенков17 февраля 2013 г., 02:41

    Хорошая вещь - Fitnesse, хочется продолжения с примерами применения :)

    ОтветитьУдалить
  2. Готовлю уже. На самом деле много примеров уже в самих тестах PowerSlim. Надо их просто к жизни развернуть.

    ОтветитьУдалить
  3. Вопрос из взбаламученной народной массы: как быть с параллельным выполнением?

    Допустим, есть тесты в виде трёъ стадий A1A2A3 (A1 - подготовка данных, A2 - процессинг данных, то, что делает продукт и надо тестировать, A3 - обработка результатов). Соответственно, B1B2B3,...,N1N2N3,.....Z1Z2Z3.

    Практика показывает, что выгодно выполнять вместе A2,B2,...,N2,...,Z2 (просто за одну обработку данных можно обработать много разных типов данных, а обработка время занимает).

    Отсюда имеет смысл готовить данные сразу для A1,B1,...,N1,...,Z1 шагов и совместно же проверять результаты A3,B3,...,N3,...,Z3.

    Как это размещать в фитнессе? Размещать по тестам A1A2A3, B1B2B3 не выгодно - время на тест умножается почти на кол-во тестов.

    ОтветитьУдалить
  4. Саша, в лоб ответить сложно. Ближе к жизни можно пример? Потому что в теоретических изысканиях, можно еще и не такое придумать. На моей практике не было такой необходимости. Тут же главное не забывать про то, что тесты не должны друг другу мешать и должны запускаться независимо. Но вообще, PowerSlim позволяет запускать команды одновременно на нескольких хостах. То есть должна работать запись вида (имена серверов через запятую, и пока без пробелов)
    |script|remote|server1,server2|
    |eval|cmdToRun|
    Аналогично должно (судя по коду slim.ps1) работать и Query. Но я пока не использовал. Это вам поможет?

    ОтветитьУдалить
  5. Макс, разделение тестов хорошо, но у нас тут оно реализовано через разделение входных данных и результатов: подаётся пачка входных данных, потом работает продукт, потом полученные данные сравниваются с входными (и правилами).

    Если ради каждого теста запускать процессинг, это накладно.

    Что касается параллельного выполнения - в простом случае это же просто один и тот же код выполняется в разных лабах, разве нет?

    Будем думать, потому что сейчас это тоже неудобно, если хочется запустить совсем мало тестов для отладки.

    ОтветитьУдалить
  6. А как насчёт задания переменных?

    Если надо задать хост вверху таблицы или результат для сравнения, то тут надо задать переменную фитнесом (define).

    И задаётся это, к примеру, на страничке типа suite.

    Если надо задать значение в пауэршельный код, то тут подойдёт пауэршельная переменная (потому что код заэскейплен !- -! и эскейпы внутри кода недопустимы: а как его дебажить, каждый копи-пейст станет пыткой).

    И задаваться эти переменные могут только на страничке типа test, потому что она исполняемая.

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

    Какие есть солюшены у передовиков фитнессо-строения по этому поводу?

    ОтветитьУдалить
  7. Да, один скрипт будет выполняться на разных лабах.

    ОтветитьУдалить
  8. могу предложить организовывать большие PS скрипты в сценарии, а настройку делать через их параметры, дабы избежать проблем с дебагом и эскейпом. Итого имеем "чистые" PS скрипты без включения в них fitnesse переменных. А при вызове сценария в качестве параметра передаем fitnesse переменную.

    ОтветитьУдалить
  9. С разными лабами есть другое ограничение: можно запустить слим-клиента под разными кредами на разных хостах, но нельзя передать разные креды для тестов.
    Т.е., в таблице можно задать несколько хостов, на каждом хосте омжно задать под кем стартует слим-клиент.
    Но вот беда - если есть массив кредов (скажем, массив имён и массив паролей), как сделать так, чтобы хосты расхватали массив по элементику?

    ОтветитьУдалить
  10. Похоже, что так сильно проще: дело в том, что если выполняется более-менее размерный скрипт (строчек двадцать), у скрипта несколько аутпутов. И где-то посреди скрипта происходит эксепшн (неважно, хотим мы выполнять код дальше или нет).
    К строке таблицы вида | show | eval | многа_кода | прирастает столбец, говорящий, что .ToString() привинтить не к чему. Это вместо толкового эксепшена.
    Нужный эксепшн где-то теряется и не выводится.

    ОтветитьУдалить
  11. на удаленных хостах запускается по 1-му "управляющему" слим-серверу (я бы его называл сервером, а не клиентом) с портом по умолчанию. а дальше через него через eval запускаются вспомогательные с указанием порта и кредов под которыми запускаться. дальше тесты уже работают с поднятыми вспомогательными серверами запуская скрипты ремоутно с указанием нужного порта и код тестов будет выполняться в контексте заданном кредами.

    ОтветитьУдалить
  12. А передастся ли код скриптов "по воздуху" (по слим-протоколу) или придётся раскидывать их по каждому слим-клиент хосту (не особо большая проблема, правда, подкачать версию скриптов).

    ОтветитьУдалить
  13. код реализующий сценарии передается "по воздуху" :)

    ОтветитьУдалить
  14. Я имел в виду не те креды, под которыми работает слим-клиент.
    Типичный юзкейс: лаба domain1 и лаба domain2.
    Слим-клиенты работают под domain1\... и под domain2\...
    А мне надо на каждом хосте передать как параметр domain1\user1 и domain2\user2 соответственно, ну или в едит бокс вбить. Вот как список кредов раскидать по слим-клиентам без сложного селектора в фитнес-таблице?

    ОтветитьУдалить
  15. хмм, затрудняюсь. Но я бы не стал делать такой мега-тест на одной странице. Можно попробовать сделать заготовку, а потом ее уже использовать через include в тестовых страницах, которые будут ее настраивать нужными кредами и потом реально запускать.

    ОтветитьУдалить
  16. Я бы не сказал, что это мега-тест :) Просто параллельная настройка продукта, который работает в своём домене и под своим юзером. Не селектор же делать switch ($hostname).
    Можно, конечно, подумать о нескольких мелких фитнесах, импортящих страницы с кодом или один большой фитнес, у которого есть пачка кредов, а мелкие фитнесы вызываются из большого с нужными кредами.
    В общем, есть поводы поизвращаться/понастраивать :)

    ОтветитьУдалить

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются.

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.