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

Тестируем с помощью 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).
    Можно, конечно, подумать о нескольких мелких фитнесах, импортящих страницы с кодом или один большой фитнес, у которого есть пачка кредов, а мелкие фитнесы вызываются из большого с нужными кредами.
    В общем, есть поводы поизвращаться/понастраивать :)

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

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

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

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

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

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе...