KoffeeKoder


  • Testing the User Interface Automated Vs Manual
    published on 6/20/2008 9:50:38 PM
  • In a perfect world all tests should be automated. Unfortunately, we don’t live in a perfect world and software development is far from being perfect. Most of the unit tests written for an application targets the domain layer. For a developer it is the heart and soul of the application. Unfortunately, users really don’t care about any layers. For them the interface of the application is the application. So, the question at this point is how do we unit test the user interface. There are tools like Watir and WatiN that helps to automate the UI testing. I have discussed the usage of those tools in some of my blog posts.

    Unit Testing ASP.NET Pages Using WatiN
    Unit Testing ASP.NET Pages Using WatiR
    Testing Nested WebControls Using WatiN
    Programmatically Start WebServer to Run WatiN Tests

    The scenarios that I explained in my posts were very simple. In practical application we have complicated interface which results in complicated unit tests. Take a look at the following unit test which is used to confirm that the in-place editing is done correctly for the GridView control.



      [Test]
            [RollBack]
            public void should_be_able_to_edit_and_update_the_category()
            {
                using (IE ie = new IE(_url))
                {

                    ie.TextField("txtName").TypeText("hello world");

                    var gvCategories = ie.Table("gvCategories");

                    var selectedRow = gvCategories.TableRows[1] as TableRow;
                    
                    Assert.IsNotNull(selectedRow, "row is null");

                    var editLink = (from Link l in selectedRow.Links
                                   where l.Text == "Edit"
                                        select l).SingleOrDefault();

                                  
                    editLink.Click();

                    gvCategories = ie.Table(Find.ById("gvCategories"));
                    gvCategories.Refresh();

                    selectedRow = gvCategories.TableRows[1] as TableRow;

                    selectedRow.TextField(new Regex("txtCategoryName")).TypeText("edited!");

                    var updateLink = (from Link l in selectedRow.Links
                                      where l.Text == "Update"
                                      select l).SingleOrDefault();

                    updateLink.Click();

                    gvCategories = ie.Table(Find.ById("gvCategories"));
                    gvCategories.Refresh();

                    selectedRow = gvCategories.TableRows[1] as TableRow;               

                    Assert.AreEqual("edited!", selectedRow.TableCells[0].InnerHtml.Trim());
                }
                    
            }



    As, you can see the above unit test is complicated and difficult to write. And that is the main reason that developers are reluctant to write these unit tests.
     
    There are also certain scenarios where automated testing will not work. This includes visualizing the elements on the screen on a certain event. You might be able to write those tests but still you won’t feel comfortable by just getting the green bar and will be forced to run it manually and see the effect with your eyes.

    So, automated testing is great but in some complicated scenarios where you are testing a group of controls or nested controls it might be overkill. For those complicated scenarios simply fire up your browser and manually test the application.