FitNesse allows clients and non-technical people to contribute to testing. Since they mostly deal with end-user interfaces, the question of writing user interface tests with FitNesse comes up often. FitNesse and FIT do not support the testing of user interfaces out of the box, but they can integrate nicely with other tools for this job. This allows us to use the functionality of UI-specific test frameworks, but keep all the benefits of FitNesse such as being able to write tests in plain English. In this chapter we find out how one such framework can be integrated with FIT and FitNesse to automate web user interface testing.
The user interface is typically the most volatile part of a software package. It is heavily influenced by workflow rules and usability constraints, not to mention all the eye candy intended to seduce potential buyers. Maintaining UI-specific tests and keeping up with all the layout changes requires a lot of effort, so the benefits of user interface tests are rarely on the same level as the benefits of business domain tests.
![[Tip]](../images/resources/tip.png) | This chapter has grown into a separate project |
|---|---|
Since the first edition of this book was published, I expanded the idea described in this chapter and released it as an opensource project. See http://fitnesse.info/webtest for more information. |
However, a few cleverly chosen web UI tests can make our work a lot easier. The trick is to focus on the right things to test. Because of the workflow constraints, it is hard to peel the onion and get to business rules and objects. Testing the business domain through the UI is probably not the best choice. Acceptance tests for business rules are much easier to write and maintain when they work beneath the user interface. Usability and exploratory tests are typically done on the user interfaces, but they are hard to automate. Checking whether something is usable or not requires a human touch, because usability is subjective. Exploratory tests are random in nature and are not a good candidate for automation.
There are, however, two types of GUI tests that it makes sense to automate:
Workflow and session control tests
Face-saving tests
User interface tests should mostly be focused on the customer experience and benefits. With FitNesse they can look almost like a user manual. These tests are good candidates for your clients to write on their own, if you can get them involved.
![[Important]](../images/resources/important.png) | Don't waste too much time on UI tests |
|---|---|
It makes no sense to go into unit-level detail with UI tests for most applications. Business logic and all functionality should typically be enclosed (and tested) in the lower layers of the system. Having said that, there are examples of applications where UI logic and the workflow are major selling points (like video games). It’s up to you to decide how much of the user interface should be covered by tests. In general, the more tests the better, but don’t waste your time. In most cases, it is better to spend time cleaning up the code or writing more business rule tests than to spend time trying to get 100% UI test coverage. With web UIs, tests run significantly slower then if they were connecting directly to business classes. So these tests should definitely be avoided in the basic test suite that people must run on every code change. This is one more argument for testing business logic beneath the UI, not with it. |
Workflow control is typically handled in a layer above business rules, so we have to use a test suite focused on the user interface to verify important parts of the workflow. This includes session control: checking whether pages refuse access if a user is not logged in or does not have a certain security role.
In practice, the UI layer is not subject to as many tests as other layers, because we focus on testing business rules. But the user interface is the only thing that customers actually see and experience. A silly UI problem, like a misspelled URL in the login form, can effectively prevent people from doing anything useful with the system. Although such mistakes can be corrected relatively quickly, they are quite embarrassing. Mistakes like this do happen. That's why I recommend always running a quick human test on a system before the release, even if the code is completely covered by tests. Automating key usage scenarios to verify the full path from the GUI down to the database also helps, because automated scripts can be checked every day. These tests should not replace the half-hour human test before the release, but they are a useful aid that can provide early warnings of problems. I call these tests face-saving,[29] because their primary goal is to prevent embarrasment.
In our test application, key business scenarios might be logging in from the home page and purchasing a ticket for the next draw.
| Web site code |
|---|---|
Web development is not the subject of this book, so I am not going to explain how to develop web sites or actually go through building one for this chapter. The goal of this chapter is to show how to test web pages in practice. So we are going to use a very simple web page with a login form, and a dynamic handler that verifies the username and password. If you want to look at the code actually used in this example, see Web code. |
So, let’s do a test for one of our key business workflows. Here’s what we want to automate:
User opens URL http://localhost:7711/ (which is where our test site is)
User types testuser into username field
User types testpassword into password field
User clicks Login
Page reloads in less than three seconds
Page contains text You have logged in
| Why did IE stop working after the test? |
|---|---|
If Selenium Remote Control does not shut down correctly, or you don't close the browser window, IE might keep the connection settings set by Selenium during tests. This can also affect MSN messenger and other programs that use an embedded IE browser. Go to Tools, Internet Options, Connections, LAN Settings and check whether the Selenium file is still being used as the automatic configuration script (see image below). Uncheck the box and IE should start working again.  |
![[Note]](../images/resources/note.png) | Stuff to remember |
|---|---|
|
[29] See http://gojko.net/2007/09/25/effective-user-interface-testing/ for a more detailed discussion of face-saving tests.
