2
votes

We are using Selenium and Fitnesse for UI testing, where we open Firefox and perform all the UI related actions - click, fill fields, press button etc.

As part of our current test framework, FitnesseRoot has the SetUp/TearDown defined, to open/destroy the browser instance. All the Suites and Tests (around 300 in number) use the SetUp/TearDown as part of the UI testing.

I am trying to replace one of our simple tests with new fixtures for API testing, because API testing is way faster than the UI testing. The test itself is working fine, but the problem here is that even though my REST fixtures do not require a browser instance, SetUp opens it and TearDown tries to close it, but returns an exception (since the test under execution points to API driver class, while the methods in the TearDown belong to the UI Driver class).

I cannot remove the SetUp/TearDown, since it has an impact on 300 test cases, as mentioned above. Is there any way I can prevent one specific test from using the SetUp/TearDown? Or point the TearDown back to the UI Driver Class, so that the test does not throw an exception?

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 |     

Actual test:

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

TearDown:

|script              |
|logout              |
|destroyDriver       |
2

2 Answers

1
votes

What I tend to do is organise my tests into suites: a front end and back end one for instance. The front end ones get a setup that starts selenium, the back end ones do not get that. So the setup is not at the root level, but (at least) one down.

Actually I tend to start selenium in a SuiteSetUp rather than in a setup and reuse the driver between tests. I find that speeds the tests up quite a bit. Closing the driver is then done in SuiteTearDown. Nested suites can override a parent's SuiteSetUp (and SuiteTearDown), by defining their own.

I expect that also works in your situation. Define one ( or more) separate suites for the API tests and give those suites a setup and teardown not using selenium. I haven't tried it but I expect the parent's setup and teardown to be ignored in that case.

0
votes

Thanks for your response, but instead of distributing the tests in different Suites, I used the following to switch drivers:

SetUp => !|script | |start| my UI driver class|${SERVER}|${PORT}|FIREFOX|${PAGE_PATH}.${PAGE_NAME}|${‌​PROXYSERVER}| |debug mode |false | |$my_UI_DRIVER= |get fixture|

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

TearDown => |script | $my_UI_DRIVER | |logout | |destroyDriver |

The SetUp opens the browser as mentioned in the UI driver class. My Fitnesse test points to the API driver class and executes my test. TearDown points back to the UI driver class and closes the browser. Hence, my test is working fine without any errors/exceptions. This way I can combine both API and UI in one test.