Testing ASP.NET Web Applications

5.8. Automating the UI as an Object Model

Although the first approach is good for single isolated tests, it is not very scalable when it comes to full UI testing. The main problems are that the tests are difficult to read because they are very tight in controlling the browser and the UI — this means the actual test is hidden behind this. Secondly, if you need to make a change, then you will need to reflect this in a lot of different places. Because of the browser control nature, you have to duplicate a lot of the steps.

The second approach is to treat the UI as an object model. The aim is abstraction. You want to abstract away from the underlying browser control and from interaction with the UI framework, such as WatiN. Instead, you want your tests to be interacting with objects with meaningful names and methods that in turn interact with the UI framework. Next you'll see how the previous test could be rewritten taking the object model approach. Notice that there is no mention of the browser, buttons, click events, or waiting for pages to finish loading. Instead, you'll talk in terms of how Google works. You create an instance of a Google object, you set the search term, and you call the Search method. You can then verify that the result contains the text you expect:

[Test] public void Search_Google_For_ASPNet() { using (Google google = new Google()) { google.SearchTerm = "asp.net"; google.Search(); string expectedString = "The Official Microsoft ASP.NET Site" Assert.IsTrue(google.Result.Contains(expectedString)); ...