The broken concept of a Page object, or Why Developers Should Be Responsible For Test Automation

Preface: I am in the middle of writing a series of posts about test automation frameworks architecture. I am still going to continue that series, even though this posts kind of devaluate the whole test automation framework concept a bit. Sorry for that, just can't stop ranting.

Looking though the internet I spotted a couple of posts where some test automation specialists were talking about "page object" "pattern"/"model", as it was something special they had invented.
Well, I also have something to say about "page object".

"Page object" may be described as pattern that allows us to decouple thing you can do with web page (external interface describing test/business logic) from the real implementation code you will have to use to actually get things done with this bloody web page. If one heard about GoF patterns, she may think about "page object" as "page adapter" or "page facade". Which does not sound too test automation specific, may be that is why "test automation specialist" tend to prefer cool "page object" term.

That leads me to the other rather shameful thought about "page object". I think, one of the most important reasons for the existence of the concept in the first place, is to hide untestable nature of the application from the test code. On pretty every blog post about page object you read that you need page object, so when UI hooks gets changed yet another time you won't have to update every bloody test case, just lovely "page object".

Which may sound as a reasonable idea, and even work some times. However I have two questions for you:
  • Does it fix the real problem (untestable and unstable UI), or just mitigates the symptoms?
  • What is the reason to touch same UI in 200 of tests? Does not it look like, you know, test duplication?
My answer for the first question would be that "page object" does not fix the problem. It makes it actually worse. It seems that "page object" allows developer to break the UI even when functionality and appearance didn't change at all. Then, "test automation specialists", (instead of kicking that bastard's ass) will just "fix page object". I have seen an example of this just yesterday, and I am sure that was wrong.

Second question is more complicated. But, seriously, if you have access to application code, you will always prefer to limit UI tests to the extent that you just can't have more then a ~5 tests touching same UI.

From the implementation perspective, if things done right, it is usually does not make much sense to do any complex testing (like, data combinations, negative cases, different Unicode symbols and other crap) from the UI level (you can test it in some other place). So why would you write more then 3-5 tests for the same UI?

That is one of the reasons why I think developers (not some "dedicated test automation" specialists) should be responsible for writing test automation for the application they develop. It is much more efficient.

I do believe, that when developer feels the pain of writing and maintaining UI tests she would pay more attention to other test types and specific test hooks, ultimately achieving an effective test automation.

Also, I hope that developer would probably rather prefer making application UI more stable and testable rather then using "Test Automation Frameworks" with "Layers" and "Page Objects" to mitigate the mess they have created.

And I hope we still friends.



  1. The page object pattern tracks the application state during test execution. Each page object function returns a page object, representing the application state after each action on the page. Only in extremely simple applications, or in an ideal world, would they not be needed.

    1. Hello Brian,

      Could you please elaborate what you mean by "tracks the application state" and how it correlates with application simplicity or complexity?

      In case of overcomplicated UI and untestable architecture we indeed may need a page object to test the mess. What I am thinking though, is that is not a cure, but pain-killer.
      If we address testability we should be able to test 95% of business logic not ever touching UI, leaving only with 5% of UI specific code, which we may test with simple tests using Selenide for example (

      We also may choose not to automate this part at all, if we fill that ROI is negative (which more that possible).

      Test automation is not always about catching each and every issue, it is often about efficiency of QA efforts (by QA I mean the process, not team).


Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.2 - Two-layered architecture

Test automation framework architecture. Part 2.1 - Layered architecture example

Test automation framework architecture. Part 2 - Layered architecture