Should we call it Matryoshka Programming or Onion Code?

Some time ago I actively participated in discussion on one of Software Testing Club forums, where I mentioned that studying programming through record/playback tool is a bad approach. Recently I had to review some test scripts and I was reminded of that again.

There are some programming practices that recommend coding so that the code best fits execution criteria – performance, memory management, etc.
And there are some programming practices that recommend coding so that the code is human-friendly – easy to read, debug, and maintain.
“Seems like now we have a practice that promotes neither execution-friendly nor developer-friendly coding”, – that’s what I thought looking through endless layers of code block which contained 12 (TWELVE!) nested “If..Then..Else” constructions with 2 loops buried between them.

Of course I can not provide the actual source code to show you but I’ve quickly baked a similar construction to illustrate it (although I didn’t put THAT many stacked “If..Then” operators).

If Browser("title:=Google.*").Page("title:=Google.*").Exist Then
 If Browser("title:=Google.*").Page("title:=Google.*").WebEdit("name:=q").Exist Then
  If Browser("title:=Google.*").Page("title:=Google.*").WebEdit("name:=q").CheckProperty("disabled", 0) Then
   Browser("title:=Google.*").Page("title:=Google.*").WebEdit("name:=q").Set "test"
   If Browser("title:=Google.*").Page("title:=Google.*").WebButton("name:=Google Search").Exist Then
    Browser("title:=Google.*").Page("title:=Google.*").WebButton("name:=Google Search").Click
   Else
    Reporter.ReportEvent micFail, "Google Search", "Failed to find Google Search button"
   End If
  Else
   Reporter.ReportEvent micFail, "Google Search", "Input box is disabled; couldn't type search query"
  End If
 Else
  Reporter.ReportEvent micFail, "Google Search", "Failed to find input box on Google Search Page"
 End If
Else
 Reporter.ReportEvent micFail, "Google Search", "Failed to find Google Search Page"
End If

Does the code above remind you of something?

“A matryoshka doll is a set of dolls of decreasing sizes placed one inside the other” (Definition and picture from Wikipedia).  “A set of matryoshkas consists of a wooden figure which separates, top from bottom, to reveal another figure of the same sort inside, which has, in turn, another figure inside of it, and so on…The artistry is in the painting of each doll, which can be extremely elaborate“.

Key points in this analogy are the following.

• Same functionalities (checking whether object exists and available) were repeated one inside the other.
• Extensive manual coding effort – each step had to be elaborated all over again  (and will have to be tested, and maintained…)

Another analogy is illustrated by the picture below.

An onion has multiple layers that one has to peel to reach the core. And in the core, the code presented has two simple test steps to perform: input a search query and submit it by pressing a button. Those steps require two lines of code. The all other lines of the code are generic service functionalities and are not parts of the test logic.  And yet they are all wrapped around business/test functionality making it hard to understand without tears. Moreover, they are redundantly repeated for each step instead of being implemented and called as reusable components.
 

In the next post I will explore ways to peel an Onion Code to make its sweet test logic core accessible outside and to keep its hard service functionalities hidden inside.

Can you share your findings and analogies in the mean time?