Monthly Archives: March 2014

Something for a Friday Afternoon (Wednesday Edition)

[On Fridays, I’ll try to post something, usually off-topic, that I think is interesting.]

[We’re travelling to NOLA for a family gathering Thursday through Sunday, so here’s an early Friday.]

Two amazing birds are in this video. Be sure to stay for the second bird, beginning at 1:42.


Our Friend, CopyFrom()

Ok, so in your CUIT (Coded UI Test) you’ve successfully completed a search for an HTML table in the app. The object found is a UITestControl, which is a very generic object.

Though the UITestControlobject has data for an HTML table, it is largely unaware of that: it does not offer properties and methods that are table-oriented. (You can see its properties and methods in the doc for UITestControl).

What if it could be made into something more table-like? Well, we’re in luck!

There’s another class, HtmlTable, that has all the properties and methods we’d want for a table. You can see those properties and methods at the doc for HtmlTable.

This class is especially useful because it hides a lot of troublesome wrinkles: Is the first child of the table element a row element? Or a table header element? When you access the rows via property HtmlTable.Rows, it doesn’t matter. The first row is the first row, and not the header (if there is one).

So how to convert from the one to the other? CopyFrom!

If the UITestControl table you found is in variable control, you would write (in C#)

HtmlTable table = new HtmlTable();

And that’s it! You can work with the table as an HtmlTable object instead of the generic UITestControl object.

The really good news is that this same conversion is available for dozens of HTML-oriented classes. See a listing of many of the relevant classes in the doc for HmtlControl (in the section “Inheritance Hierarchy” at the top, click link More...).

Something for a Friday Afternoon

[On Fridays, I’ll try to post something, usually off-topic, that I think is interesting.]

A Plan for the Improvement of English Spelling

For example, in Year 1 that useless letter c would be dropped to be replased either by k or s, and likewise x would no longer be part of the alphabet. The only kase in which c would be retained would be the ch formation, which will be dealt with later.

Year 2 might reform w spelling, so that which and one would take the same konsonant, wile Year 3 might well abolish y replasing it with i and Iear 4 might fiks the g/j anomali wonse and for all.

Jenerally, then, the improvement would kontinue iear bai iear with Iear 5 doing awai with useless double konsonants, and Iears 6-12 or so modifaiing vowlz and the rimeining voist and unvoist konsonants.

Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi ridandant letez c, y and x — bai now jast a memori in the maindz ov ould doderez — tu riplais ch, sh, and th rispektivli.

Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.

Mark Twain

Burdette Lamar

Getters and Setters

Some test automation I “inherited” a while back had a textbox whose getter method was called GetCurrentBrick (not quite its real name).

Take just a moment to try to guess what the setter was called. The answer here is white text on white background, so select between the arrows to view: > Brk <

[Just discovered that it’s not obvious how to highlight text on some mobile devices, so will say here that Brk is the name given to the setter.]

Nice, huh?

If there is going to be a getter/setter method pair (and we'll get to that question in a minute), they should have consistent naming. A start would be GetCurrentBrick and SetCurrentBrick. Actually, though, a textbox doesn’t have any content but the “current” one, so it would be better to say just GetBrick and SetBrick.

But why have two methods at all? The setter should return the previous state, in case the caller needs to restore the previous value. Therefore it’s simple and useful to have a single method that always gets and can, optionally, set.

Thus a call to method Brick() with no value parameter is a pure getter, while a call with a value parameter Brick("in the Wall") is a setter that returns the previous value. This means there’s only one method name to learn, and it’s pretty intuitive that the value-less call is a getter, while the value-bearing call is a setter.

The exact implementation of this method would depend on the programming language at hand. In C#, which is what I’m using at the moment, the signature for a method of type String would be:

  • public String Brick(Locator locator, String value=null)

where the method tests value for nullity and acts accordingly. (The locator is something that tells CUIT how to find the control. I’ll be writing about class Locator in a future post.)

There will be text that’s displayed but can’t be set, and for that we’d need:

  • public String Brick(Locator locator)

And text that can be set but not got (password, for example):

  • public void Brick(Locator locator, String irretrievable)

Of course none of this is new. But as the anecdote at the beginning of this post demonstrates, Dr. Johnson’s famous observation remains all too true: People more frequently require to be reminded than informed.

Burdette Lamar

Keep Your Page Objects DRY

The page object pattern is an extremely important pattern that’s well described over at Selenium. If you don’t know about the pattern and haven’t read their article, go read it now.

Everything said in the article also applies to dialogs, so don’t be misled by the word page. They could just as well have written about dialog objects.

The article also suggested a wonderful practice that’s new to me:  Having a method in a page object return another page object. I’m now doing this whenever a method lands the application on a different page. Example:  Completing the sign-in on the sign-in page lands the app on the home page, so method SignInPage.SignIn returns a HomePage object.

So what can I add?  Well, DRYness! (Don’t Repeat Yourself!)

[This post originally emphasized inheritance. David Green commented that composition is more flexible. I agree, so I’ve revised the post.]

I’m going to talk about composition and inheritance here because the language I’m using is C#. The corresponding strategy in a different language might be different: Ruby mixins, Python modules, etc.

Let’s get to it. The web application I’m testing, like many others, has some elements that appear on many but not all of its pages. For the sake of DRYness, it’s useful to handle these elements with composition and inheritance (or other code-sharing strategy, as above).


The first class for page encapsulation is the base class _BasePage. I’ve given the class name an underscore to emphasize that it’s not an ordinary page class — it is not itself the encapsulator of a single web page.

Every page class derives from _BasePage.

What’s in _BasePage? Only those things needed for every page in the application:

  • A Context object.
  • Support for the Locator objects that will tell CUIT how to find controls.

I’ll write about classes Context and Locator in other posts.


In the application:

  • The menu bar appears on every page except a popover and the sign-in page.
  • The footer appears on every page except a popover. In this particular app, a popover is sufficiently page-like to be treated as a separate page.

The other elements that are shared among pages are handled via composition, because different pages may have different mixtures of those elements.

Each of the compositors is a class whose constructor accepts a page object. The compositor defines locators and adds those locators to the given page.


Almost all pages have the menu bar, which has the basic navigation for the application. The page objects for such a page declares an instance variable _Menubar menubar and assigns it a new instance of _Menubar, whose constructor adds the appropriate locators to the page object.


Like the menu bar, most pages have footer boilerplate. The page object for such a page declares an instance variable _Footer and assigns it a new instance of _Footer, whose constructor adds the appropriate locators to the page object.

“Tabbed” Pages

A few pages in the application have tab-like behaviors. On such a page, there’s an upper area with a title and two or more links (tabs). Below there’s content that can be changed by clicking one of the links.

Let’s say that there are four tabs, for the four seasons.

Then a class _Seasons encapsulates the elements in the upper part of the page.

Each of the tabs is encapsulated by a page object (derived from _BasePage). Each page object declares an instance variable _Seasons seasons and assigns it a new instance of _Seasons, whose constructor adds the appropriate locators to the page object.

So each season tab has its own locators, plus those in _Seasons, plus any it chooses to get from _Menubar and _Footer.

Now that’s DRY!

Burdette Lamar

Initial Post

This blog will mostly be about testing software, but I’ll likely go off topic from time to time.

At first, I’ll mostly be blogging about the work I’m doing right now, which is building test automation.  My language for this work is C#, and my test framework is Visual Studio (Premium or Ultimate only) Coded UI Test, which I’ll call  by the unattractive but shorter name, CUIT.  My test target is a web application.  CUIT also supports testing Windows applications, which I may also be doing soon.

I am building what some people have been calling “hand coded” CUITs.  That is, I am not using record/playback (or even record), and I am not using CUIT’s UI maps.  (Now that’s hand-coded!)

Soon I’ll be writing about exactly what I’m doing, as well as how and why.

Burdette Lamar