It is good practice to test as much as possible on API level, as that results in the fastest and most robust tests. If you design your application the right way, you can test the complete business logic by just stimulating the business model via APIs. So test automation in general should not focus on the user interface (UI) level unless for testing the UI itself. For that, tools like Selenium WebDriver are positioned. Selenium WebDriver is an open source library that enables driving web browsers and mobile devices as if it were an end user. It uses drivers to interact with the main browsers (most notably Google Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari) to act as a user would. This allows for automated testing of web applications without having to alter the applications under test.

But WebDriver itself is not a test tool - it just interacts with the user interface of web applications. How people typically deal with this is coding the tests in a unit test framework using a programming language like C# or Java, using Webdriver calls along the way. There are quite a few disadvantages to that approach:

• You cannot specify test cases before you have written the code.
• The tests you make this way are generally quite hard to maintain, since they mix low level technical steps with high level test workflows. When user interfaces change, it is often a lot of work to adapt the tests to this.
• If you rely on coding tests, you need to have developer skills and developer tools, and that is often not a dependency you want to take.

Good test cases are structured such that they require a minimum of maintenance effort. Maintainable test cases distinguish between business rules, workflows, building blocks and technical steps. Business rules explain how the business works. Workflows show how you could test a scenario involving the business rule – but still independent from technology. These workflows are assembled from parameterized building blocks, which hide the technical steps that specify exactly how to implement the workflows in the chosen technology.

Here is an example of this layering concept:

The sweet spot of many UI automation tools is at the technical steps level. For example, the recording tools in Coded UI records the individual technical steps (sometimes building blocks), but you never explicitly get to the workflows. The same drawback applies to Selenium IDE, a plug-in for Firefox that allows you to record tests. This makes tests that are solely automated by Coded UI or Selenium IDE quite hard and labor intensive to maintain. Furthermore, these kinds of tools are heavily developer focused and are often seen as too technical for testers.

We can overcome this issue by introducing FitNesse into this type of testing. Using FitNesse allows testers to maintain the workflows and accompanying data.

As we saw before, Coded UI requires Visual Studio to be installed, which is a dependency you don’t always want to have. The functionality that Selenium provides is much like Coded UI (under the hood that also uses Webdriver for Web testing). The advantage of Webdriver based tests above Coded UI is that you can use Selenium stand-alone – you only need to deploy a few assemblies to be able to run your tests. But it has the same focus on the technical steps that Coded UI has. WebDriver does not provide the capabilities to implement workflows. You can of course implement the workflows in code, but still the drawback would be that the tests are harder to modify; you would need a developer for even simple data changes.

FitNesse on the other hand is accessible for testers, using a Wiki to create test cases, but it does not support web-based UI testing. Combine the two and you get the best of both worlds. The only thing you need is a fixture that uses Selenium WebDriver to provide a base set of building blocks for UI testing.

The fixture provides building blocks such as:

• Select a browser to do the test (Chrome, Firefox, Edge, Safari)
• Open a URL
• Wait for a page to load
• Check if a certain element exists
• Click an element
• Check if a certain text is present on a page
• Enter a value to an element
• Submit a form
• Extract data from a table

By combining FitNesse and Selenium this way, you can maintain the workflows in FitNesse and cleanly isolate the technical details from the business logic. That is what the fixture in this repo is about.

It is assumed that you have installed FitNesse according to the readme. We will also install new tools as browser drivers as siblings to the FitNesse folder. If your setup is different, then change folders according to your folder structure.

If you want to use Internet Explorer (or Edge in Internet Explorer mode), Selenium documentation states that it requires all Internet Explorer zones to have the same protection setting: either all Protected Mode on, or all Protected Mode off. If you do not do that, tests with Internet Explorer do not work reliably. That is not an issue with the Selenium Fixture or with Selenium Webdriver, but with the architecture of Internet Explorer.

To be able to run the Selenium Fixture, you will need to set the SLIM port to something else than the default (which is using pipes). The easiest way to do this is setting the SLIM_PORT variable in plugins.properties.

SLIM_PORT=8475

If you run into trouble, check out the Troubleshooting page.

Acceptance Testing Wiki