How Do I Invoke Thee? Let Me Count The Ways: The Physical Object Model


Most test cases that manipulate a user interface are tightly tied to the current details of that UI. What the test case is doing often gets lost in the details of how it is doing it. We abstract away these implementation details by wrapping our application UI with a Physical Object Model that lets us reference the UI without having to know the details of how it is accessed.

We take this a step further by using a controls abstraction layer to smudge UI details into similarity. If a check box in the UI is changed to a radio button, everything that knows that check box is a check box now has to be updated to talk to it as a radio button. We don’t want to have to make that change, especially when a control simply changes to another type without affecting its semantics. If you really do care about a control’s type you can to talk to it as such, but we have found those occasions to be few and far between.

Comments (8)

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

  2. My previous post hinted that the Physical Object Model takes advantage of some underlying magic that…

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

  4. I think my team – much of Microsoft, in fact – is going about testing all wrong.

    My team has a mandate…

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

  6. Patrick comments on my When To Automate post:

    I am confused by your third bullet in that unstable/newly…

  7. Something I’ve been experimenting with recently is Test-Driven Design (TDD) for user interfaces (UI)….

  8. First up today was Linda Hayes talking about Cost Effective Test Automation Strategies. She grabbed…