Как обойти Fitnesse SetUp/TearDown для отдельного теста?

Мы используем Selenium и Fitnesse для тестирования пользовательского интерфейса, где мы открываем Firefox и выполняем все действия, связанные с пользовательским интерфейсом - щелчок, заполнение полей, нажатие кнопки и т. Д.

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

Я пытаюсь заменить один из наших простых тестов новыми приборами для тестирования API, потому что тестирование API намного быстрее, чем тестирование пользовательского интерфейса. Сам тест работает нормально, но проблема здесь в том, что, хотя моим REST-приборам не требуется экземпляр браузера, SetUp открывает его, и TearDown пытается закрыть его, но возвращает исключение (поскольку тест при выполнении указывает на класс драйвера API в то время как методы в TearDown принадлежат классу драйвера пользовательского интерфейса).

Я не могу удалить SetUp/TearDown, так как он влияет на 300 тестовых случаев, как упоминалось выше. Можно ли как-то предотвратить один конкретный тест от использования SetUp/TearDown? Или укажите TearDown обратно на класс драйверов пользовательского интерфейса, чтобы тест не выдавал исключение?

SetUp:

|import            |
|com.myapplication.fitnesse.ui|
|com.myapplication.util.restclient.fixtures|

!define slim.flags {-s 200}

!|script |                                                                                           
|start| my UI driver class|${SERVER}|${PORT}|FIREFOX|${PAGE_PATH}.${PAGE_NAME}|${PROXYSERVER}|
|debug mode          |false |

Актуальный тест:

!define TEST_SYSTEM {slim}
| script | my API driver class | server ip:port | username | password|
| login |
| do something...|

TearDown:

|script              |
|logout              |
|destroyDriver       |
Источник

2 ответа

Решение

Спасибо за ваш ответ, но вместо того, чтобы распределять тесты по разным наборам, я использовал следующее для переключения драйверов:

SetUp =>! | Script | | Начать | мой класс драйвера пользовательского интерфейса |${SERVER}|${PORT}|FIREFOX|${PAGE_PATH}.${PAGE_NAME}|${‌ PROXYSERVER}| | режим отладки | ложь | |$my_UI_DRIVER= | получить приспособление |

Actual Test =>! Define TEST_SYSTEM {slim} | сценарий | мой класс драйвера API | ip: порт сервера | имя пользователя | пароль | | вход | | сделать что-нибудь... |

TearDown => | script | $ my_UI_DRIVER | | выйти | |destroyDriver |

SetUp открывает браузер, как указано в классе драйвера пользовательского интерфейса. Мой тест Fitnesse указывает на класс драйвера API и выполняет мой тест. TearDown указывает на класс драйвера пользовательского интерфейса и закрывает браузер. Следовательно, мой тест работает нормально без каких-либо ошибок / исключений. Таким образом, я могу объединить API и пользовательский интерфейс в одном тесте.

Источник

Что я обычно делаю, так это организую свои тесты в наборы: например, внешний и внутренний. Входные получают настройку, которая запускает селен, а задние - нет. Таким образом, настройка не на корневом уровне, а (по крайней мере) ниже.

На самом деле я склонен запускать селен в SuiteSetUp, а не в настройках, и повторно использовать драйвер между тестами. Я считаю, что это немного ускоряет тесты. Закрытие драйвера затем выполняется в SuiteTearDown. Вложенные наборы могут переопределять родительский SuiteSetUp (и SuiteTearDown), определяя их собственные.

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

Источник
Другие вопросы по тегам