UI testing isn’t brittle…its the test that is

This morning I had the chance to chat with Andrew Chen from Auto GUI Test Service.  The conversation we were having was about the different types of automation tools that are on the market today.  And it was during this conversation that I began to form a thought in my head.  It’s not that UI testing is brittle, its that the tests themselves are.

What I mean is that traditionally people have done record and playback type automated testing.  Every test is independent of another, thus when one feature changes all of the tests break.  I believe much has been to propogate this idea.  But the reality is that if your test is componetized then this test is no more brittle then a unit test.

An example

Traditional way – I have a 3 test cases where as part of them I have to navigate from Point A to Point B.  6 months after I have created the 3 unique tests we add a Point C between A and B.  At this point all 3 tests have to be updated and in many cases completely rescripted.

Component Way – All three tests share a common function that navigates from A -> B.  When 6 months later Point C is added, it is only this function that needs to be updated.

Now I believe many people will say that they already do this, but the tests are still brittle.  But then I ask the question, if you make a change to the system, and the test breaks, how is that any different then a xUnit or Fitnesse test breaking for the same reason?  I think the answer is that it’s not, it is just the conception that is.