5.1. Can UI Automation Be Achieved?

User interface (UI) testing is often thought of as a manual process because of the many problems associated with this type of testing. To ease the repetitive nature of this manual testing, developers and testers often resort to third-party tools to "record" mouse positions and raise click events on the screen. The test scripts created from these third-party tools are very difficult to read, because the tool that generated the script created a script so complicated that a human would have a very difficult time maintaining it. Again, because of this fact, UI test scripts begin to rot, and are deleted because they no longer work. Although these tests are easy to set up, they often make the UI tests very brittle because any change to the UI can invalidate the positioning and logic recorded within the test. As a result, most testers and developers have started to abandon these types of recordplayback tests.

Is it okay to delete tests? There are strong advocates on both sides of the fence of this issue. Many believe that tests should never be deleted, that it can be reworked if the code being tested has been refactored, but a test should never be deleted. Others believe that if a test is no longer useful, the test should be removed. We think that deleting test code should only be done if it won't increase the cost of finding a defect or add documentation regarding the behavior of the application.

As you read through this chapter, you will learn not to fear automated user interface testing and learn that it can be successfully applied to a project. However, it's important to keep in mind that there is a cost to automation. In almost all situations it will take you much longer to write a program that clicks a button and reports the result than it would to manually click that button and see what it does. Many testers and developers assume that automated UI testing will replace manual testing, but this is never the case. Manual testing will not go away.

Great testers/developers are able to weigh their experience with the benefit of what automation will buy them. After you have read through this chapter you will realize that UI testing is easy, but that creating meaningful tests is a difficult skill that can only be obtained by practice. Some development shops have very few automated UI tests and use them as smoke tests (you can read a definition of these in the list of functional tests in the next section). If the automated UI tests they have created run without failures, the application is good enough for manual testing to be performed. Other development shops have created very elaborate test suites to test every aspect of the application covering very fine details, such as the background color of a web page. Both of these cases are acceptable, and the testers/developers have decided what they need to get out of automated testing.

With all that said, what does UI testing do for web applications? Automated UI testing is great for those few moments after code is checked in to tell you if something in the UI is broken. If something is broken, you'll know that the quality of the code is not sufficient to run the manual tests on this code. As with other types of tests, UI testing helps flush out bad requirements, finds issues with features that don't match requirements, and provides a nice safety net to prevent against regression.