A Peek Behind The Curtains

With the LFM defined and hooked up to Execution Behaviors it makes sense to move on to defining the Physical Object Model.

The POM is often the simplest part because it's just a straightforward API around the user interface. Given Surveyor's UI:

A sketch of Surveyor's UI

a likely POM would be:

public class UIApplicationWindow : UIWindow
    internal UIApplicationWindow(UIObject applicationWindow)
        : base(new Window(applicationWindow)) { }

    public UIQuestionSetButton SwitchToNotYetAnsweredQuestions { get { } }
    public UIQuestionSetButton SwitchToSkippedQuestions { get { } }
    public UIQuestionSetButton SwitchToAnsweredQuestions { get { } }

    public UIQuestion CurrentQuestion { get { } }

    public UIButton MoveToPreviousQuestion { get { } }
    public UIButton MoveToNextQuestion { get { } }
    public UIButton FinishSurvey { get { } }
Although the POM is a very thin wrapper around the UI, omitting UI elements used only for layout can vastly simplify the POM. For example, Surveyor's UI uses stack panels and assorted other layout mechanisms to format its user interface, but none of these are important for execution or verification and so the POM does not mention them.

Much of the POM uses predefined classes that provide standard behavior (such as UIWindow, which has Close, Move, and Resize methods), but many applications require some custom controls as well. Custom controls that merely add functionality to a standard control are straightforward to handle: simply derive from that standard control and add the necessary behaviors. Surveyor's question set navigation buttons (the ones that allow the user to switch between those questions they haven't yet answered, those they've skipped, and those they've answered) are nothing more than styled radio buttons, so UIQuestionSetButton class could be defined like so:
public class UIQuestionSetButton : UIRadioButton
    internal UIQuestionSetButton(UIObject theQuestionSetButton)
        : base(theQuestionSetButton) { }

    public int QuestionCount { get { } }
where UIRadioButton provides the expected ability to select itself and to report whether it is selected.

Other cases that involve a truly custom control are handled by deriving from (wait for it...) UICustomControl. An example of this in Surveyor is the current question:
public class UIQuestion : UICustomControl
    internal UIQuestion(UIObject theQuestion)
    : base(theQuestion) { }

    public string Question { get { } }

    public UIRadioButton GetAnswer(string name) { get { } }

    public UIButton ClearAnswer { get { } }
    public UIButton SkipQuestion { get { } }
Although the UI does not clearly separate it as such, a question has multiple parts: the text of the question, the set of possible answers, the button to clear the selected answer, and the button to skip the question. Grouping those related concepts into a single object helps make the POM easier to work with and understand (for me, at least).

In the main, implementing the individual properties is trivial. UIQuestion.Question's getter is just:
public string Question
        UICustomControl value = this.FindDescendant<UICustomControl>("Question");
        return value.Name;
Its ClearAnswer getter is even simpler:
public UIButton ClearAnswer
        return this.FindDescendant<UIRadioButton>("ClearAnswer");
FindDescendant wraps the tree walk services that Avalon and UIAutomation provide. Generics (new in version two of the .Net Framework) takes care of casting the generic object those services return to the specific type of control we're looking for. (And yes, I normally pull those inlined constants out to named constants!)

To use the POM, simply dot your way down the tree:
// Logical.Application.MainWindow returns a UIApplicationWindow.
UIRadioButton answer = Logical.Application.MainWindow.CurrentQuestion.GetAnswer(answerId);
Logical.VerificationLog.VerifyTrue(answer.IsSelected, "Answer " + answer.Label + " is selected");

As I said, straightforward stuff!


*** Want a fun job on a great team? I need a tester! Interested? Let's talk: michhu at microsoft dot com. Great coding skills required.

Comments (3)
  1. My previous post hinted that the Physical Object Model takes advantage of some underlying magic that…

  2. Your Logical Functional Model lets you write test cases from your user’s point of view, test cases that…

  3. In many of my posts I have alluded to the automation stack my team is building, but I have not provided…

Comments are closed.

Skip to main content