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

Question

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

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

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

Я не могу удалить 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  | 

Answer 1

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

SetUp => | сценарий | | начало | мой класс драйвера UI | $ {SERVER} | $ {PORT} | FIREFOX | $ {PAGE_PATH}. $ {PAGE_NAME} | $ {PROXYSERVER} | | режим отладки | false | | $ my_UI_DRIVER = | получить приспособление |

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

TearDown => | script | $ my_UI_DRIVER | | выход | | destroyDriver |

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

Answer 2

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

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

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